Access is a file-server database.  That means that the back-end, no
matter where it is located, is opened by the front-end just as if the
server was a simple hard drive.

The PC the back-end is on needs to be fairly fast, because it is
reading its hard drive and serving data across the network, but that's
about all.  It is not doing any Access processing.  In fact, Access
doesn't need to be installed on it at all.

So, the performance issue might be caused by several things:  network
performance, slow back-end PC, disk on the back-end PC being nearly
full, application design, etc.

Try each user separately.  If one is faster than the other, the
culprit might be the speed of the user's PC or network connection.

Armen Stein
Microsoft Access MVP
www.JStreetTech.com

Peer-to-peer networks do not allow as many concurrent connections as a
server in a client-server. That may, or may not, be the source of your
performance issue.

MVP Tony Toews has a lot of excellent performance suggestions at his site
http://www.granite.ab.ca/accsmstr.htm. Take a look at these...

 Larry Linson
 Microsoft Access MVP

The first thing to try is the persistent connections fix.

The three most common performance problems in Access 2000 or newer
are:
 - LDB locking which a persistent recordset connection or an always
open bound form corrects (multiple users)
 - sub datasheet Name property set to [Auto] should be [None]
 - Track name AutoCorrect should be off

If the problem is for everyone when starting up the MDB then it likely
needs a decompile.

For more information on these, less likely causes, other tips and
links to MS KB articles visit my Access Performance FAQ page at
http://www.granite.ab.ca/access/performancefaq.htm

Tony