Multi-User Slowdown

[iamchemist]

At our local food pantry we are running Access-based software on a Windows XP desktop server. Volunteers who are dealing directly with Clients work on two Windows XP laptop computers that are wirelessly connected to the desktop computer via a wireless G network. Thus, the laptop computers are essentially acting as two smart terminals, both of which are accessing the the software that resides on the faster desktop server.

This arrangement can be very, very slow, and I would like to speed it up in some way. It is common for characters (ex, a client’s first name) in a particular field of a form to only appear slowly as you type. For example, for a short name like “sam”, you might get the name completely typed into the appropriate field before the initial “s” ever shows up on the laptop computer screen. When the first name does show up and you Tab to the "last name" field, you might not see the cursor show up in the "last name" field for several seconds. Typically, you see the blue bar at the top of the Access form screen turn from light to dark blue at the same time as you see your cursor show up in that "last name" field. All of this sounds a bit like the timing is being dictated by how long it takes Access to get back to that particular laptop computer. Indeed, if the software is run directly on the desktop computer server, one never sees this slowness. If it is being run from either of the two laptops, but only one laptop is actually running the software on the server, then you again DO NOT see this slowness. As soon as a second laptop computer begins running the software from the server, then you see this slowness in a dramatic way.

I have also learned that at no time is the server being significantly taxed. Looking at Windows Performance Diagnostics on the server I can see that at no time is the amount of available CPU power or the amount of memory (4 Gb) being greatly consumed.

Does anyone have any suggestions about Access parameters that I might adjust to speed things up?

Thanks,

Ron

 

[MajP]

You did not mention if the database is split into a front end and back end. If that is not the case, then that is absolutely the first step.
Back end has the tables only and resides on the server
Front end has forms, modules, codes, queries and resides on each workstation. Tables are linked to the front ends.

 

[missinglinq]

As MajP has said, you absolutely have to split this database, and the statement

both of which are accessing the the software that resides on the faster desktop server.

would make one think that you either have an unsplit db or if split they're both using tth same front end. If you don't split it, as MajP suggested, eventually the slowness will be the least of your problems! Multiple users accessing an Access file on a shared drive will, sooner or later experience corruption and loss of data.

That said, the slowness may be due to the wireless connection. I seem to remember that Access does not do well with these.

The Missinglinq

Richmond, Virginia

There's ALWAYS more than one way to skin a cat!

 

[iamchemist]

Thanks to MajP and Missinglinq,

You are correct, our current Access application is not split. I have learned that there is a new version of our application in the works, which is split. Given that the new version is slated to be completed within a couple of months, it does not make much sense for me to put in the effort of splitting our current application.

A worthwhile bit of learning from our situation is that running a multi-user Access application over a wireless-G network is not a good idea. There are many others using this same non-split Access application with wired Ethernet, who do not experience the slow performance that we do with a wireless network. The wireless network does not result in any data corruption, but it does slow things down drastically.

 

[MajP]

Regardless, wired or wirless you have to split the db with every user having their own front end. The point is not debateable, even if you have not experienced anything yet.

If I was going wireless I would replicate my backend so that on the network is the master backend, and each wireless user has both a front end and their own replicated backend. Wireless users open their db, synch to pull down current updates, but do their work on their local replicated backend. When all done they synch back up. Wired users link to the back end directly from the front end of their local machine.

 

[iamchemist]

MajP,

I have been assuming that splitting our database/application would be rather difficult to do, and so I would just wait a couple of months for the new split version of the application to arrive.

Perhaps splitting our current database is easier than I think, and I should try it anyway. Would you give me some idea of what is involved to split a database application?

Thanks,
Ron

 

[MajP]

There is actually a wizard to do it, or you can do it manually. The help file provides very detailed instructions. Read that first to get specific questions. I can split a database manually in 5 minutes. It should not take you more than a half hour to split and then test. Obviously try it first on a copy.

 

[iamchemist]

MajP,

Thanks a lot! I'll go and start reading.

Ron