Unable to open db if not the first user

[shabbott]

Hi. I have an application which uses access db files for the back end. It's shared on a PC with a number of other PCs. One particular PC cannot open the application once someone else has it open. If it opens it first, it runs fine and all the other PC's can run it fine. But if it's not first, it just hangs trying. Now I'm fairly sure it's the ldb file that it's struggling with because if I click on that file from Windows explorer while the application is hung, windows explorer hangs as well. I can click on the mdb file and get it's properties but not the ldb file. As soon as everyone else logs out of the application, the "hung" PC application springs to life and works fine. If it was a file permission problem I would have thought it wouldn't get access regardless of whether others are logged on or not. The PC the db resides on is Windows 7 32 bit. The PC having the problem is Windows Vista Business. The other PCs that don't have a problem are a mixtrure of Win 7 and Vista. Any ideas gratefully received.

[pkstormy]

This script might help:

https://www.accessforums.net/code-re...sier-7572.html

[shabbott]

Thanks for the reply pkstormy. I tried that today and it didn't help. I'm still at a loss. Someone has suggested to me that I try a different nic in the PC which I will try next week. Again, it's one of those things where something that doesn't make sense is probably going to fix the problem so it's just a matter of trying. I've already done a complete reinstall of the PC which didn't help. Very strange.

[pkstormy]

Some other things I would check:

1. Permissions for that user (to both fe and be). A user without both read AND write permissions can lock an *.ldb file regardless if it's the be or fe.
2. MSAccess options for that user. Check to see if it's set to open MSAccess files exclusively or shared.
3. MDAC. If this just started happening after splitting the db and linking the tables into the fe, the MDAC could possibly be the problem (although MDAC problems are rare but can be a problem if you've applied service packs or re-installed office).
4. Network connections. (Although you'd probably notice this with other apps, but if that pc maps the drive where the be resides differently or is unsteady, this could cause the *.ldb to lock up.) Are you using citrix or anything for the user to connect to the backend folder or is the drive just shared? I'd possibly try re-mapping/re-sharing that drive for that pc.
5. MSAccess version - I found MSAccess 2010 doesn't play very nicely with linked tables in a frontend and other users are using older MSAccess versions (such as 2003 or 2007) on that same mdb file.


Are you having an issue with the backend or frontend?

The script in the link in the attachment is designed to make a copy of a frontend 'source' mdb/mde/accdb/accde file and then launch that copy (after attaching the user's loginID.) Hence, no 2 users are in the same *.mdb file (and thus each have a separate *.ldb file and a specific user can never lock out another user (from the frontend)). Each user opens the mdb via using the script and you can have hundreds of users in your app without problems (since again, each is in their own fresh 'copy' of the frontend source mdb each time they run the script.) I like this method better than copying the fe to each user's desktop (which is a pain to keep code updated). If using the script didn't resolve your issue on the frontend, then I'm guessing something on that specific setup of that pc is problematic since it would be the same as if the user on that pc opened up their own copy of the fe. If the be is causing a problem, I'd more suspect a permissions type problem to the folder/be. Often a user will have read permissions but doesn't have the necessary write permissions. This is the most common cause of an *.ldb becoming locked for others once a specific user opens it (usually on the backend mdb).

I hope this helps.