New Developments within a Database

[sammylou]

Before anyone says "check these forums for an anwer", I have done so already! My problem is that since converting from Access 97 to 2002, I am finding it a real pain in the *** that I cannot develop any new forms, modules etc whilst the users have the DB open because I am not logged in exclusively. In v97 I could happily code stuff whilst others were logged in, as long as it was new objects that they couldnt see or were currently using. I have though about splitting the Db into Front End/Back end and have ready numerous threads on this. but doesn't this mean that everytime I make a change that I will need to roll out the front end to all the users? This would be a complete pain as I would have to go round to everyones PC and do this. Can I split it and keep both front & back ends on the networked drive? Also I thought that splitting the DB would slow it down drastically? I also have a security workgroup for the DB and am not sure whether splitting it would affect this

My users are getting cross cos I keep having to ask them to come out whilst I import new stuff from an Acceptance Database but at the same time they keep pushing me for new developments.

Thanks

 

[The_Doc_Man]

Welcome to the world of configuration management.

Make yourself a copy of this DB. You don't care about having current data, just current copies of the code. Make a copy of the MDB file, too. Adjust this copy so you have exclusive access and nobody else has any access at all. Keep it on a private disk or on your local hard drive.

Now when you users want new features, implement them in the copy. When you are done, import the new code to your master DB. Recompile code, etc.

This won't completely alleviate your problem, but what it does is minimize your exposure. While you are editing/testing in your new-features DB, you are in it exclusively and your users aren't affected.

Now, this next suggestion is the tricky part, but it is the only way to live in a multi-user shared environment, and you have to "sell" it to your users as a cost of doing business...

Set aside a maintenance day. Tell your users that the ONLY ONLY ONLY way they'll get the new features is to go along with you on this. Do all DB compactions, upgrades, repairs, etc. during this maintenance time.

You must ALSO realize that mucking a running system is a bad thing, which is why I can't get upset with Bill Gates about this change to project editing. It is actually the "right" thing to do. In fact, I'm so astonished that he did something right that I have to believe someone else told him it was needed. Or maybe someone threatened his family.

 

[geraldcor]

The way I take care of it is by having my local database linked to local tables. I can do whatever I want to test and manipulate the front end, I can even change data in the tables to test things. All users have a frontend copy of the database on their computers linked to the backend on a server. To update, I make a copy of the local database and copy it to a folder called NetworkDatabase. I link this frontend to the proper server backend and then i made a .bat file to copy this "real" database to all users computers. I just type
Copy C:\NetworkDatabase\IDFL_forms.mdb "\\Middleman\c\MainDatabase\*.*"
etc for all of the computers in the network and the .bat file plugs away replacing the old version with the new one. You do need to make sure everyone is logged of the database for this to work but it takes about 30 seconds or so (Depending on how many users) to update. I just tell everyone they need to be of at 3 pm or something for quick maitenance. They seem to like this method. I forgot to add, you should compact and repair the "Network Database" before you copy this one to all of the user's computers.