Categories: MSDN / DotNet / Java / Scripts / Linux / PHP Ask - La ask - La Answer

Access problem in multiuser environment

I have an .mdb located on a network folder. It is in 2000 format, however most of the users now have Office 2003 & Windows XP. The database options are configured to open with Shared access as default. There are no user groups or permissions in the DB. All users have Modify rights to the folder in which the .mdb is stored.

When a user opens the database an .ldb file is created. As I understand it, this means the database is NOT opened with exclusive access.

My problem? Once a user has opened the DB, no other user can open it! If another user attempts to open it, nothing happens. Access does not start, no error messages appear.

This problem does not occur with computers who have Windows 2000 & Office 2000 installed. This problem also does not occur in my C:\tmp folder (WinXP & Office 2003) which is shared across the network. The only difference is that C:\tmp has Full rights, whereas the network folder has just Modify.
[968 byte] By [RedTilIDie] at [2007-11-11 8:27:28]
# 1 Re: Access problem in multiuser environment
The first thing you need to do is configure the folder for full access for all users of the database. I don't believe modify is sufficient since the .LDB file must also be able to be deleted when the last user closes the database. In addition, you don't want one user to have ownership of the .LDB file since this could prevent other users from accessing it.
pclement at 2007-11-11 23:47:05 >
# 2 Re: Access problem in multiuser environment
Okay, Everyone has been given full control........but still no luck. Same problem happens
RedTilIDie at 2007-11-11 23:48:10 >
# 3 Re: Access problem in multiuser environment
Could you be a bit more specific as to how you are opening the file?
pclement at 2007-11-11 23:49:09 >
# 4 Re: Access problem in multiuser environment
Double-clicking the icon in Windows Explorer.

However, it seems that if I open Access & try to open the DB by clicking File -> Open & then navigating to the network folder it does work!! :SICK:

This is not a perfect solution, however, because most users have shortcut icons on their desktop which definitely do NOT work if another user has the DB open.
RedTilIDie at 2007-11-11 23:50:08 >
# 5 Re: Access problem in multiuser environment
Is the path to the database a mapped drive letter or are you using a UNC path? It sounds like the Registry entry that handles the file association may need to be fixed.
pclement at 2007-11-11 23:51:07 >
# 6 Re: Access problem in multiuser environment
The database does open by double-clicking for the first person. It's just when others try to open it that double-clicking fails!
RedTilIDie at 2007-11-11 23:52:14 >
# 7 Re: Access problem in multiuser environment
OK, but are you using a mapped drive letter or UNC path in the shortcut? Does it make any difference if you specify the Start in folder in the shortcut?
pclement at 2007-11-11 23:53:07 >
# 8 Re: Access problem in multiuser environment
We are using a mapped drive letter. If I change the path to UNC, the shortcut works!!

What's the problem? I've searched the MS KB & cannot find any articles dealing with this issue. UNC path names are not an adequate solution.

Cheers
RedTilIDie at 2007-11-11 23:54:10 >
# 9 Re: Access problem in multiuser environment
Is the behavior the same if you use a UNC path instead?
pclement at 2007-11-11 23:55:13 >
# 10 Re: Access problem in multiuser environment
No, the behaviour is not the same. If I change to a UNC path in the shortcut's properties then everything works as normal. So there must be an issue with the DFS, correct?
RedTilIDie at 2007-11-11 23:56:14 >
# 11 Re: Access problem in multiuser environment
I'm afraid I can't explain why. It should work with either but I've heard of instances where there were issues using one or the other. Typically it relates to performance.

UNC paths are generally more flexible and reliable. The problem with mapped devices is that they can disconnect and also that not everyone may use the same mapped logical drive letter for a network resource.
pclement at 2007-11-11 23:57:12 >
# 12 Re: Access problem in multiuser environment
Thanks for your help. I really appreciate it. At least I have narrowed down what the problem is!
RedTilIDie at 2007-11-11 23:58:15 >
# 13 Re: Access problem in multiuser environment
OK - I had some issues with this very thing. WHat I had done, is Upgrade the database to 2003 format. When accessing DATAACCESS pages (If you have them) This will then prompt users to download (OFFICE XP WebComponents) if they do not have them already which allows better comms and compatibility. Ensure the MDB attributes are FULL ACCESS... NOt read only. Ensure the Network PATH is sharable by ALL FULL ACCESS - Do not MAP a drive letter to the PATH.

Once I updated the MDB to 2003 it worked better for DATA Access Pages -

Don't know if this helps.
bar23 at 2007-11-11 23:59:22 >
# 14 Re: Access problem in multiuser environment
Your problem looks very much like a similar issue I have experienced recently; When mapping a network drive *on a different network* from the command prompt or batch script, the Access 2002 client seems to not trust the other network and treats it like the internet. This results in an error message.

For me, the quick and dirty work-around was to map the drive manually in Windows Explorer in stead of the batch script, after which the Access client didn't reject the mdb. However, the should be a better solution for this...
smacdevil at 2007-11-12 0:00:22 >
# 15 Re: Access problem in multiuser environment
I just had the same problem, and found the solution.
Using a DFS root, you have a fully qualified domain name instead of a server name in your path
\\something.something\share
instead of
\\server\share
therefore putting it in the Internet Domain in Internet Explorer.
Add the FQDN into your Intranet Zone in Internet Explorer, and all is well.

http://support.microsoft.com/?id=303650

Good Luck!
benburns at 2007-11-12 0:01:24 >
# 16 Re: Access problem in multiuser environment
Thanks Benburns, that's that just what I was looking for, but too lazy to search at the time =D
smacdevil at 2007-11-12 0:02:22 >