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.