Can't open an 'in use' MDB from network drive, but get an atypical error message

[lonwinters]

The error is "Windows can't open this file: "databasename.ldb", then gives you the options of searching or browsing for the program that will handle the file type.



The database will open as first user from any computer, and the same message occurs not matter which computer attempts to open it as a second user. This only occurs with one MDB file, there are several others that work fine except with the occasional performance hit and "File in use" error. This MDB was is actually a modified version of one of the others but it was edited on a different computer and has many changes.

I've tried all the fixes and work-arounds I could find, including Splitting. The settings are the same as the original, working files - shared mode, record level locking, etc. There is no password, or special user groups set up. The only thing I can think of is something to do with network permissions, but then if that were the case it would seem the first user would have problems, and it would affect all databases, not just this one.

Has anyone seen or heard of this particular error message displaying related to concurrent users and in use files? I know that using a single MDB file on a network driver is not best practice, but a second user should at least be able to open the file.

Any ideas and help appreciated!

[tanvi]

To resolve this behavior, you must make sure that all users who open the database have read & write permission for the folder in which the database is located. If you are using a security-enhanced Access database, you must make sure that the users who open the database also have Read permission and Write permission on the folder that contains the workgroup information (.mdw) file. For more information please visit this link: http://support.microsoft.com/kb/289681

[lonwinters]

I'm not using the MDW features at all. I'll also have my client's IT check the permissions also.

But, if it was a permissions issue - then wouldn't that mean they would not be able to open the database, even if no body else had it open? No one has a problem opening the database as a first user and that means they would have to have write permissions in order to create the lock file. Plus, they are able to open the other databases (but those are in different folders on the network drive.

Could this be one of those things that no matter what the root problem is, that it just manifests in ways that are just not consistent or reliable?

Thank you for your response - I really appreciate it!

Lon

This is yet another example of being hired to take over an existing project where the foundation is flawed and ends up being more work than just starting over from scratch.

[tanvi]

I have read in so many forums about this error and I did not found any other cause of the error. This is typically a folder permissions problem.The database engine is unable to create the corresponding. LDB in the folder where the database is located, which results in this error. I have found some useful post:

http://social.msdn.microsoft.com/For...5-444415ac9ee1
http://www.mrexcel.com/forum/microso...use-error.html


Hope the solution will help you to resolve the error!!

[John_G]

Hi -

Your question states: "Windows can't open this file: "databasename.ldb",
Normally, you don't want to try to open an ldb file; it is created and maintained by MS Access; it is not a database and is "not for human consumption". Access creates the ldb file when an mdb file is first opened, and puts a lock on it so that no non-Access applications can open it.

Post back if you get the same error when trying to open an mdb file, that is an MS Access database.

HTH

John

[John_G]

One other thing to check is the default open mode of the database. In A2003 you use Tools - Options - Advanced, and set the default open mode to "Shared" or "Exclusive". I don't know where that is in A2007, but might the database that is giving you the problem be set to Open Exclusive?

John

[lonwinters]

Now we;re getting somewhere!

Yes, the message specifically states it's trying to open the LDB file - but it occurs when the user attempts to launch the MDB file! That why I thought this was an atypical error message for a common problem.

Any user can launch the MDB file (which is set to shared) thus creating the lock file in the process, so it would seem that folder permissions are not the problem. When a second user opens the database, Access also opens the LDB file which from what I understand, contains certain information including who also has the database open, and updates the lock file adding that user to the list.

Since my last post here before this one, I did learn that they can open the database using the method of first launching Access, then browsing for the file. The initial report was that this method was not working, but now they at least have a work around which the do not like, they are more "shortcut on the desktop" sort of people.

This problem occurs with other programs too at times, though it's not about sharing a file. It's happened in Flash quite a bit, the file has to be opened within the app, not by the double click. I just don't know why this should matter, it must be how the OS handles the commands and the order in which they're processed.

[John_G]

From what you have said, your problem is not with MS Access, but with how your establishment has implemented it. The clue is in the fact that once MS Access is running, the databases can be opened. We had much the same type of problem, where Access would not open databases directly.

Try this to see if it resolves the issue, assuming that the MS Access .exe file is on your c:\ drive.

Create a shortcut on the desktop as usual, but in the target, use the full path to msaccess.exe and the mdb database. For example:

"C:\Program Files\Microsoft Office\Office\MSACCESS.EXE" "C:\Data\Msa_Dat\Accounts\accounts_New.mdb"

This is for Windows XP - I am not familiar with Win 7 yet.

It turned out that our system was set up such that if you just clicked on a .mdb file in a directory, it did not execute MS Access directly, but always looked for updates or fixes first. That process was flawed, and using the explicit path to MS Access bypassed it.

HTH

John