Split Database Principle Question

[Fattire]

We have a shared windows network here and several access databases on it. They are all split, but very slow once more then one person uses them. I noticed recently that everyone has shortcuts to the front end and not the actual front end sitting on their desktop. The front end and the backend always reside in the same directory.

Wouldn't that be why its so slow? Shouldn't the front end be copied to everyone's desktop, or is that wrong?

Someone said they do it that way so that the developer doesn't have to go around to everyone's machine and copy a new file to their desktop whenever he made a change to it.

Your thoughts?

 

[JoeAtWork]

Someone said they do it that way so that the developer doesn't have to go around to everyone's machine and copy a new file to their desktop whenever he made a change to it.

The solution to that is to have their shortcuts point to a batch file that copies the newest version of the front-end to the user's computer and then automatically starts Access with that MDB.

And yes, its better for everyone to have their own copy of the front-end.

 

[Fattire]

I knew it! Wow now thats great idea... I haven't done batch programming in 20 years but I'm looking into it, thanks Joe!

 

[RoyVidar]

There are several good solutions to distributing new front end around. The one I've used, when the need arose, is created by a guy calle Tony Toews, and can be found here

http://www.autofeupdater.com/

Roy-Vidar

 

[MajP]

I would add that it is ESSENTIAL not just better that everyone runs from a front end on their local machine. Running a split data base where the front end is on the server is slow and will often lead to corruption of the database.

However there may be other things you have to fix to make your split db run faster

http://www.fmsinc.com/tpapers/faster/

http://www.fmsinc.com/MicrosoftAccess/DatabaseSplitter/Index.html

 

[Fattire]

I think I may have to rebuild every single database we have here after looking at all these websites, nice links, thanks!