Usually this occurs due to one of the following:
1. One of the FE's doesn't have the tables refreshed after the table has been modified design-wise. MSAccess is trying to 'resolve' conflicts on the FE linked tables where it doesn't match the changes in the BE.
2. The network itself is slow or slow for one of the users, causing disruption for others. Possibly one of the user's has a slow connection or trying to map the network drive inefficently (which makes me wonder since you said "in certain network environments" and "once one FE is opened"). - See #3 below.
3. One of the user's doesn't have full (read/write) permissions to the folder the FE/BE is in or they have the mdb opened and have been 'sitting' on a record for a period of time (and is possibly 'locking' the *.ldb file or causing MSAccess time in trying to 'resolve' who's in the *.ldb file) See here:
http://www.dbforums.com/6274786-post19.html
for a technique where you can have unlimited users open the FE without affecting any other users. I use this all the time and it works great.
4. There's some kind of code in the main opening form (or startup coding) causing disruption. Possibly timer type coding on a form or if a data type form, the form is not opening efficiently (ie. it's trying to open 'ALL' records versus using criteria to only open 1 record.) Combined with subform's, this can delay form efficiently (and opening an mdb) quite a bit. Main Menu type startup forms should 'only' have buttons and not be bound to ANY table (ie. DON'T use the switchboard.)
You can also see here for code to automatically refresh/create an ODBC DSN if the tables are linked SQL Server tables (
http://www.dbforums.com/6282465-post37.html) If however they are MSAccess linked tables, I usually don't write code to refresh them on startup (since I use the technique in #3 above.)
