Calendar - Multi-User Access DB - Best method

Print Page | Close Window

Multi-User Access DB - Best method - Please Help

Printed From: Codejock Forums
Category: Codejock Products
Forum Name: Calendar
Forum Description: Topics Related to Codejock Calendar
URL: http://forum.codejock.com/forum_posts.asp?TID=8352
Printed Date: 23 November 2024 at 11:40am
Software Version: Web Wiz Forums 12.04 - http://www.webwizforums.com

Topic: Multi-User Access DB - Best method - Please Help

Posted By: vbuser
Subject: Multi-User Access DB - Best method - Please Help
Date Posted: 09 October 2007 at 2:17am

I've read your article: http://codejock.com/support/articles/com/calendar/cp_3.asp - http://codejock.com/support/articles/com/calendar/cp_3.asp

I am still not clear what the best and simpler method is; can you please give me your recommendation, bound, memory, etc.

I have a working VB6 demo app using the built-in access data provider. This app. will be used in a multi-user enviroment, I also like to add custom fields and I'd like to use an 'employees' table instead of your resources table for resources... Should I work with data in memory & save every time there is a change? Should I modify the SQL custom class to use Access instead, I dont really want to create myselft a big mess of a problem hard codeing all this if I could find a way around to use the built-in access provider and just use some code to 'adapt' to my needs... I could just keep the resources table and update it from my 'employees' table for example.

When is best to refresh/re-load data to make sure all computers can see the current calendars? Can you give me an example? Thank you!

Replies:

Posted By: sserge
Date Posted: 09 October 2007 at 4:33pm

You can use regular Access data provider for all your tasks, except: "and I'd like to use an 'employees' table instead of your resources table for resources". The problem is that all table names are hardcoded.

To use another names (and/or data structure), you have to implement custom data provider as described in the article, including writing of custom SQL scripts, and so on.

--
WBR,
Serge