Question

I have created an MS Access 2003 application, set up as a split front-end/back-end configuration, with a user group of about five people. The front end .mdb sits on a network file server, and it contains all the queries, forms, reports, and VBA code, plus links to all the tables in the back end .mdb and some links to ODBC data sources like an AS/400. The back end sits on the same network file server, and it just has the table data in it.

This was working well until I “went live” and my handful of users started coming up with enhancement requests, bug reports, etc. I have been rolling out new code by developing/testing in my own copy of the front-end .mdb in another network folder (which is linked to the same back-end .mdb), then posting my completed file in a “come-and-get-it” folder, alerting the users, and they go copy/paste the new front-end file to their own folders on the network. This way, each user can update their front end when they’re at a ‘stopping point’ without having to boot everyone out at once.

I’ve found that when I’m developing now, sometimes Access becomes extremely slow. Like, when I am developing a form and attempt to click a drop-down on the properties box, the drop-down arrow will push in, but it will take a few seconds before the list of options appears. Or there’s tons of lag in selecting & moving controls on a form. Or lots of keyboard lag.

Then, at other times, there’s no lag at all.

I’m wondering if it’s because I’m linked to the same back end as the other users. I did make a reasonable effort to set up the queries, forms, reports etc. with minimal record locking, if any at all, depending on the need. But I may have missed something, or perhaps there is some other performance issue I need to address.

But I’m wondering if there is an even better way for me to set up my own development back-end .mdb, so I can be testing my code on “safe” data instead of the same live data as the rest of the users. I’m afraid that it’s only a matter of time before I corrupt some data, probably at the worst possible moment.

Obviously, I could just set up a separate back-end .mdb and manually reconfigure the table links in the front end every time, using the Linked Table Manager. But I’m hoping there is a more elegant solution than that.

And I’m wondering if there are any other performance issues I should be considering in this multi-user, split database configuration.

EDIT: I should have added that I’m stuck with MS Access (not MS-SQL or any other “real” back end); for more details see my comment to this post.

Answer 1

If all your users are sharing the front end, that’s THE WRONG CONFIGURATION.

Each user should have an individual copy of the front end. Sharing a front end is guaranteed to lead to frequent corruption of the shared front end, as well as odd corruptions of forms and modules in the front end.

It’s not clear to me how you could be developing in the same copy of the front end that the end users are using, since starting with A2000, that is prohibited (because of the “monolithic save model,” where the entire VBA project is stored in a single BLOB field in a single record in one of the system tables).

I really don’t think the problems are caused by using the production data (though it’s likely not a good idea to develop against production data, as others have said). I think they are caused by poor coding practices and lack of maintainance of your front end code.

1. turn off COMPILE ON DEMAND in the VBE options.

2. make sure you require OPTION EXPLICIT.

3. compile your code frequently, after every few lines of code — to make this easy, add the COMPILE button to your VBE toolbar (while I’m at it, I also add the CALL STACK button).

4. periodically make a backup of your front end and decompile and recompile the code. This is accomplished by launching Access with the /decompile switch, opening your front end, closing Access, opening your front end with Access (with the SHIFT key held down to bypass the startup code), then compacting the decompiled front end (with the SHIFT key held down), then compiling the whole project and compacting one last time. You should do this before any major code release.

A few other thoughts:

1. you don’t say if it’s a Windows server. Linux servers accessed over SAMBA have exhibited problems in the past (though some people swear by them and say they’re vastly faster than Windows servers), and historically Novell servers have needed to have settings tweaked to enable Jet files to be reliably edited. There are also some settings (like OPLOCKS) that can be adjusted on a Windows server to make things work better.

2. store your Jet MDBs in shares with short paths. \Server\Data\MyProject\MyReallyLongFolderName\Access\Databases\ is going to be much slower reading data than \Server\Databases. This really makes a huge difference.

3. linked tables store metadata that can become outdated. There are two easy steps and one drastic one to be taken to fix it. First, compact the back end, and then compact the front end. That’s the easy one. If that doesn’t help, completely delete the links and recreate them from scratch.

4. you might also consider distributing an MDE to your end users instead of an MDB, as it cannot uncompile (which an MDB can).

5. see Tony Toews’s Performance FAQ for other generalized performance information.