How do I delete Access lock files?

[Gasman]

Notepad works just as well?

 

[RogerCooper]

I had problem with Notepad once, but it seems to work perfectly well when I checked.

 

[The_Doc_Man]

The problem with reading the lock file with any particular program is understanding what is in it. These days, because user-level permissions have been discontinued as a supported feature, the "username" is probably SYSTEM for every user unless it is part of a strict network domain. However, the computer ID will change from user to user and that is how you would figure it out.

 

[isladogs]

We are 23 posts in and there has been lots of excellent advice around the purpose of lock files together with why they sometimes do not get deleted.

The Issue can also occur due to coding errors particularly if one database references another.

It’s also worth pointing out that a recent bug with three of the Ease of Access features caused hanging instances of Access to be left behind. That bug was fixed in version 2405.

However, unless I missed it, nobody has explained how to delete them when Windows tells you the file is in use. Apologies if I missed this in previous posts.

To do so, make sure you have no active instances of Access running, then open Task Manager and look for any background processes labelled Access. If so, select these in turn and click End Task. Or look in the details tab for MSACCESS.EXE and do the same.
After that the related lock file can be safely deleted.

If all else fails, reboot then delete the lock file(s)

 

[The_Doc_Man]

We are 23 posts in and there has been lots of excellent advice around the purpose of lock files together with why they sometimes do not get deleted.

The Issue can also occur due to coding errors particularly if one database references another.

It’s also worth pointing out that a recent bug with three of the Ease of Access features caused hanging instances of Access to be left behind. That bug was fixed in version 2405.

However, unless I missed it, nobody has explained how to delete them when Windows tells you the file is in use. Apologies if I missed this in previous posts.

To do so, make sure you have no active instances of Access running, then open Task Manager and look for any background processes labelled Access. If so, select these in turn and click End Task. Or look in the details tab for MSACCESS.EXE and do the same.
After that the related lock file can be safely deleted.

If all else fails, reboot then delete the lock file(s)

While I agree with Colin's advice, there is one more "gotcha" in his suggested path. (I described this method and the exceptional problem that goes with it in post #9, but I'll emphasize it here.)

Colin's method works UNLESS the Access task is in a state called "I/O Rundown" - which means it was waiting for an I/O completion. As long as a task is in I/O Rundown, it CANNOT exit. More precisely, it cannot go through the internal "Delete Process" routine that reclaims its memory, and that is because at the moment, it's memory is locked due to being targeted by a kernel-level I/O request with direct memory access options. Terminating a task that is waiting for I/O completion CAN result in having that task disappear from the Task Manager's list of processes and yet leave the file still locked, because resource unlocking occurs only AFTER I/O completion (separately, on each active channel.)

Granted, this is a rare situation - but when it happens, the only solution is a reboot, which is the ONLY way to terminate a true I/O Rundown case. During a reboot for this case, you will get your normal monologue from Windows about tasks being terminated, then will find one that Windows says "waiting for task to terminate..." and it waits. It may actually give you a popup message for "terminate anyway" - or that option may be displayed as a command button under the list of things being terminated. Eventually, the reboot will work even if you have to manually select that "reboot anyway" option.

IF this reluctance to shut down happens, it might be necessary to isolate the DB file in question to test it for corruption before you let the world touch it again. If the file that was open was the lock for the FE file, probably nothing much will happen and at worst, you would have to download a fresh copy of the FE file. If the FE/BE split was done correctly, no biggie there. IF it happens where the BE file was located, that is your nightmare scenario because the lock file in the BE directory means the BE file was open. There, you DO have to worry about file corruption.

 

[John Sh]

It's actually fairly easy.
I've just had to do this after Access stopped working.
Create a new folder and transfer every thing to it except the lock file.
Delete the original folder with the lock file.
Rename the new folder with the same name as the original.
Problem solved.
Obviously on a large multi user system there will be a bit more work to do but nothing very drastic or demanding.

 

[The_Doc_Man]

Delete the original folder with the lock file.

REALLY bad advice for this specific line, because what that does is delete every file that was in the folder and closed. Hope you didn't have anything valuable in it! The folder immediately becomes "marked for delete" (assuming you had DELETE FILE permissions) and is thereafter inaccessible. The still-open files from that folder are ALSO marked for delete and inaccessible because you can't get to the containing folder. Until the cause of the file being open is discovered, those files cannot go away due to behind-the-scenes file locking. Unless, of course, you do a reboot. I'm not sure you CAN create a folder with the same name as a locked folder in this rundown state, though in that case I'm not sure.

If this actually worked for you, then something less drastic should have also worked. Windows File Locks can be relentless. And in this case I am NOT talking about the .LACCDB file but instead about an internal Windows data structure that protects open files. There is nothing the file folder that would show the file is locked, though there are CMD utilities that would list file locks for you.

The original problem, of a lock file not going away, is MOST OFTEN due to users failing to shut down Access before turning off their machine, or having the network shut down or glitch while the Access app file is still open, or using Windows Task Manager to shut down an Access instance. Anything that would cause Access to shut down before it could delete the lock files would have the perpetual locked file effect. However, it is not uncommon for the problem to stem from the user having MODIFY permissions on the app files but not on the folder containing those files.

Depending on the system holding the folders in question, if you think that everyone is out of the application, you should be able to delete the lock file. If you cannot, and this happens repeatedly, then either you have a really poorly trained user or you have a really poorly constructed app that aborts itself in ugly ways.

 

[John Sh]

REALLY bad advice for this specific line, because what that does is delete every file that was in the folder and closed.

If you first remove the files to another folder then there is nothing to lose.
My copy of access died with with files open. This was the only way I could clear the lock file.
The files in question were development files but the folder also housed accde test files and a copy of the system back end.
All operational files are on a separate system but I believe this would still work if one of the terminals went down mid stream.

 

[The_Doc_Man]

Generally speaking, when you lose a terminal for some ugly reason, an internal timer starts that counts down how long the terminal has to reconnect (if that is allowed by your IT staff, which is another question on its own). After that time-out, the internal file locking SHOULD resolve itself to the point that you can manually delete the lock file. If there were several users in the file at the time of the failure, there is a lock interaction that will take time to resolve for EACH USER via something called an "interest lock." Depending on site settings by the IT staff regarding file locks, and the fact that interest locks are involved in a thread chain that requires some memory manipulation, it could take a while.

If the user that still holds the lock isn't aware that their session is still open, the timers don't resolve anything because the interest lock senses the "keep-alive" timer on each terminal's network card. Which is why you need to "read" the lock file to get terminal IDs. Something that I used to do when I had this problem was that I kept a log of who logged in and from which terminal ID. Then I could visit every terminal listed in the lock file to ask that user to close out Access - or to run Windows Task Manager and END TASK on their left-over Access session.

 

[LarryE]

Just copy the FE to each users individual PC and re-link each one to the BE file. Then delete any FE files on the common server location. It's always been my understanding that when you open an ACCESS file, a lock file is created in both the FE and BE locations (for split applications). If each user has their own copy of the FE file, a lock file will only be created on their own PC and one will also be created in the BE file location. If a single FE file is being used by multiple users or if multiple FE files are being used in the same file location, that may cause problems.

 

[Pat Hartman]

Here is some documentation created by Isladog and it includes links to at least two versions of this useful utility. It will tell you who is logged in and that may give you a clue as to what is causing the problem. When you open the utility and point it to the database you want to check, you see yourself as a logged in user plus who ever is the one that has the file locked.