Unable to clear Record-Locking Information file

[Guest]

We currently have a problem where a number of our databases seem to retain
the Record-Locking Information / .ldb file, long after any users have come
out of the database.
This remains the case when the users close MSAccess and even when the users
shut down and reboot.
Is there any way to ensure the .ldb file gets cleared when the user closes
the database? Only this impacts on our ability to make any necessary
amendments to our databases.
Thanks!

 

[Rick B]

On thing I would look at is the Windows permissions for your users. Do they
have full permission to the folder? Can they delete?

There may be some other suggestions, but this is a good place to start.

 

[Joseph Meehan]

We currently have a problem where a number of our databases seem to
retain the Record-Locking Information / .ldb file, long after any
users have come out of the database.
This remains the case when the users close MSAccess and even when the
users shut down and reboot.
Is there any way to ensure the .ldb file gets cleared when the user
closes the database? Only this impacts on our ability to make any
necessary amendments to our databases.
Thanks!

The usual cases are users who do not shut down Access and just turn off
their computer, or a user that does not have delete authority for the
directory where the locking file is maintained.

 

[Guest]

We do have full permission. We can delete any files in the folder apart from
the .ldb files, since it believes the file is still in use, even if no users
are in the database.

 

[Guest]

Thanks, but in these cases Access is being shut down and the delete authority
is there. Have even gone so far as checking the processes in Task Manager to
delete any MSACCESS.exe, but there seems to be no access process yet the .ldb
file remains and continues to retain the ID for a user who has completely
shut down access and even rebooted.

 

[Joseph Meehan]

Thanks, but in these cases Access is being shut down and the delete
authority is there. Have even gone so far as checking the processes
in Task Manager to delete any MSACCESS.exe, but there seems to be no
access process yet the .ldb file remains and continues to retain the
ID for a user who has completely shut down access and even rebooted.

This sounds like it is only one user or maybe a few users who have this
issue. I would suggest that there may be something unique about the way
they are configured or set up that is involved.

Is there any chance that something else is holding that file open? Are
the users in question using some sort of program to view the ldb file? If
that would be the case that could explain it.

Since it is Access on the user's machine that does the delete (I
believe) that could indicate that there is a problem with Access on the
user's machine (maybe try a repair or re-install?). It would also follow
that rebooting or shutting down would have no effect on the process.

 

[Ron2005]

Try this link: http://www.mvps.org/access/modules/mdl0055.htm

it has a small access app that looks at the ldb file and will tell you
all of the users that are logged into mdb that you reference.


really neat and small, and the code for the form can be imported into
any app that you want or run standalone out of this app. With that you
may be able to tell what machine is actually holding open the ldb file
without having to try to guess.


Ron

 

[Guest]

I've had a similar problem with the ldb staying open and me not being able to
compact/repair the backend DB on a large multiuser environment.

Mostly what I found to happen was 1. The users weren't closing down access
completely and 2. Access stays open in their task manager and has to be
ended or the PC needs to be rebooted.

If I am completely certain Access is not open in their task manager and they
have closed everything down completely, and the ldb is still open, I would
need to manually delete the ldb file. The ldb file can be deleted without
harming the backend database. The ldb has remained in the past due to a slow
down or disconnect in the traffic between the fe and be.