Persistent laccdb file (3 Viewers)

[John Sh]

I had a situation where the external drive, holding the remote data files, was removed before Access was completely shut down.
This left the laccdb file on the drive and doing that which it was designed to do, lock up Access.
I was unable to do a compact and repair, nor was I able to remove the laccdb file.
I was, however, able to delete the text from the file but this did not remove the lock.
It would seem that the mere existence of the file, and not the content, is the trigger that locks Access.
A subsequent restart of the computer saw the laccdb file on it's way and Access is back to full operation.

Hopefully this little exercise will be of assistance to some other poor soul with Access all locked up.
John

 

[The_Doc_Man]

Your description confuses me.

If you remove an external drive (call it X for argument) and a back-end .ACCDB file was on X, the corresponding .LACCDB file will also be on X. If Access is able to see drive X and the .ACCDB file, it can also see the .LACCDB file. Hope you used the EJECT feature to remove the drive, because otherwise buffer flushes didn't occur and this is a way to corrupt a database!

After drive removal, the only system remnants that could be left would be "dangling" Windows file locks for X's files in the memory of the computers hosting the FE file. Since the X drive is no longer mounted, these locks are meaningless because the files to which they apply are no longer extant on the computer. There should also be NO pending I/O for any files X if you wait 30 seconds after drive removal.

If you then reconnect the X drive but don't run Access right away, you have a .LACCDB file for which there are no pending I/O requests and therefore no reason why you couldn't try to manually clean it up. You would have to do this on any computer using X as a back-end host; however, a CMD-prompt "UNLOCK" command naming the full path of the .ACCDB file should unlock any leftover Windows file locks. Once the Windows locks are gone, the .LACCDB file should be OK to be manually deleted, after which you should be good to go.

If you waited long enough before reconnecting the X drive, the Windows locks would be gone anyway due to timeout issues - but as I recall, that particular timeout is very long. A reboot would also clear any Windows file locks after which the .LACCDB should be subject to manual deletion.

Note that this logic only applies to external drives that don't have a complete system on board. If your X drive is actually a drive on another Windows computer system (i.e. you have an actual dedicated computer as a file server), THAT system retains the Windows file locks. Even if the X drive is removable in the latter case, the fact of having an active system means the Windows file locks can persist a bit longer.

 

[John Sh]

Your description confuses me.

If you waited long enough before reconnecting the X drive, the Windows locks would be gone anyway due to timeout issues - but as I recall, that particular timeout is very long. A reboot would also clear any Windows file locks after which the .LACCDB should be subject to manual deletion.

Note that this logic only applies to external drives that don't have a complete system on board. If your X drive is actually a drive on another Windows computer system (i.e. you have an actual dedicated computer as a file server), THAT system retains the Windows file locks. Even if the X drive is removable in the latter case, the fact of having an active system means the Windows file locks can persist a bit longer.

Hi Docman
The drive X only holds the data for my development files so no damage done to the active files.
X was disconnected, and the main computer off, for about 4 days and a computer restart was done, with X connected, but the accdb file persisted.
Possibly the main computer being off would stop the countdown for Windows to release the locks, just a guess.
I stripped out the text in the accdb, still unable to get into my files, then did another restart and all was well.
I got the impression that removing the lock data was the critical operation.
I am no expert on these things, so I can only report my observations.
John

 

[The_Doc_Man]

a computer restart was done, with X connected, but the accdb file persisted.

Of course it did. But you don't care about the .ACCDB file, you care about the .LACCDB file.

The .LACCDB file's life cycle (assuming a multi-user shared back end) is that the .LACCDB file is created by the first person to open the shared .ACCDB (back-end) file. Subsequent openers try to create the .LACCDB file using a "create if" type of function, and since that file already exists, no new version is created.

As users eventually sign off, each one attempts to delete the .LACCDB file, but as long as the system has a file handle open on drive X's host machine, it cannot be deleted. But for the last user signing off, that file can be/IS deleted, leaving the .ACCDB file intact and idle.

When you disconnect the X drive, that .LACCDB file's deletion, which requires visibility of the Windows file infrastructure for that drive, cannot happen because at that time file infrastructure-based operations are not possible. If you don't use EJECT to prepare the drive, then any pending DB buffers get lost and you corrupted the BE DB. BUT if you EJECT first, all pending output buffers are written back and the drive becomes logically dismounted, which again means no file operations - but no corruption either.

After a 4-day separation AND a restart, you should have been able to manually delete the .LACCDB file immediately. NO residual Windows File Lock survives a reboot of the machine hosting the drive. Windows file locks reside in system scratchpad memory, which is not preserved after a full restart. Now, if the computer went to "sleep" but power remained continuously available, locks would be more resilient. A "wakeup" remembers things that a "restart" does not. There is also the "fast boot" option that checkpoints stuff for you that would preserve file locks, but again, a complete restart doesn't preserve "fast boot" data, either.