Microsoft Access Record Locking Stopped Working

New Contributor

We have a database on a network drive that was set up for multi user concurrent access with the following configuration that had been working well until just recently. Multiple users could work in the database at the same time using the below configuration



Default open mode = Shared

Default record locking = Edited record

Open databases by using record-level locking = Yes



Firstly, the record locking file is not automatically deleting on closing of access when the database is on the network drive. C drive removes the file as per normal behavior.


Unable to open the database when opened by someone else and the record locking file is already created. Error message "already open by another user" or "could not lock records"



I believe read, write and create access to the network drive location is fine as I can manually delete the record locking file no issues.


Only started experiencing this problem after updating Office 365 on December 14. The current build used is Monthly Enterprise Channel, Version 2110 Build 14527.20340 Click-to-Run



12 Replies

Hi @Simon0916 


We are also experiencing this exact issue today on two of 8 networked systems that shared the Access Database and both have updated to Version 16.0.14701.20248 (Via 365). First system was updated on 14th Dec and the other one on the 16th .


Have you managed to resolve and , if so, did you roll back to a previous version?


Look forward to your reply


Many thanks


Seems like the same issue exists with MS Office 2016
*.ldb files are not deleted when everybody has left the database.

Please fix.

Same. This is causing major mail merge issues at the moment. Unfortunately, I have some scenarios that are not ready to be fully modernized in the Power Suite so not sure what to do with this at the moment.
Actually, it looks like you might have another update that might resolve your issue. Version 2110, build 14527.20344 indicates it would resolve your issue.
I experience the same issue with a database on setup on a shared drive. I tried version 2111 but still had the same problem. Any suggestions?
Thank you,
I reverted my two problem systems to the previous version 2111 (Build 14701.20226) and they both now work perfectly!



Was not able to get the rollback to work using the deployment tool and


setup.exe /configure config.xml


where the xml file contains:


<Updates Enabled="TRUE" TargetVersion="16.0.14701.20226" />


do you have a suggestion?

I have the same issue on Office 2013. It started after a security update was performed for Microsoft Office. I think this is the one that may have caused the problem for me: KB5002104

@Simon0916 we are having the exact same issue with Office Professional Plus 2016 on a terminal server.

Version 16.0.5215.1000 and it started around December 14th.


It only seems to affect databases on a shared drive, if you use the local c: drive there is no issue.

I also noticed that the .laccdb files that get created are 0b which is different from when they are working and they tend to be 1kb.


Doesn't seem to be fixed by latest updates so will try to roll back instead for now.


Same here Ben....we have a half dozen databases acting out - - we are currently testing if this is due to domain group policy restrictions on those specific UNC paths -- they had enough permission(s) previously but now it does not seem to be enough so we opened up their access on the folders holding those db's and all way up the chain to see if this will resolve this issue...Domain Admins dont have any problems with the databases - they are able to open/close and the lock file disappears as expected...
Hi @RAD_Colin

We ended up moving the database onto a virtual machine with a different office install - for other reasons aside from just this problem and it didn't have the same issue. I see your reply below about rolling back the version working which is good. Hopefully Microsoft can resolve this in future updates.

Hi @Simon0916!


I am supporting several Access databases using the similar conditions as you described, all of them are affected in the same manner. I am quite sure that this issue is on Microsoft's side.