"Could not lock file" with Access build 14701.20248

Anonymous
2021-12-14T19:16:08+00:00

I had a client today who could not open their shared backend database. The system displayed the error “Could not lock file”.

I determined that Access was trying to open the file in exclusive mode, even though none of the normal methods to open the file exclusively were being applied:

• The File / Options / Client Settings / Advanced / Default open mode was set to Shared

• No command line /excl  was being used

• The user had Full Control permissions for the shared folder containing the database

• Creating a new test database opened it exclusively, so that no other user could open it.

• The newly created test database could not be reopened if another user opened it,

• Several other users could simultaneously open the new test database without a problem.

The user had been using the database for normal operations for several days prior to the problem.

The user’s system has updated to build 16.0.14701.20248 today.

All other test users had build 16.0.14701.20226.

I rolled the user's Office installation back to 16.0.14701.20226 by using the Office Deployment Tool https://support.microsoft.com/en-us/topic/how-to-revert-to-an-earlier-version-of-office-2bd5c457-a917-d57e-35a1-f709e3dda841 

The problem was solved.

Can anyone else confirm that this problem exists with the latest build of Access?

Neil Sargent

Smart IT Ltd

Microsoft 365 and Office | Access | For business | Windows

Locked Question. This question was migrated from the Microsoft Support Community. You can vote on whether it's helpful, but you can't add comments or replies or follow the question.

0 comments No comments

50 answers

Sort by: Oldest
  1. Anonymous
    2021-12-20T23:05:16+00:00

    The updates for MSI builds will take a little longer, but are coming. In the meantime, you can uninstall the KB that introduced the problem to resolve the issue. You will need to reboot after removing the KB.

    • KB 5002104 for Office 2013
    • KB 5002099 for Office 2016

    Was this answer helpful?

    3 people found this answer helpful.
    0 comments No comments
  2. Anonymous
    2021-12-21T02:41:53+00:00

    To be clear: We have an "old" system with split frontend and backend database. (Application file is readonly). Starting yesterday (monday 20th) did several users report the problem in that system. Yesterday did the users say that it was working last week, but that might be due to the fact that only one user was using at a time. We can not verify that.

    First did we verify that nothing was corrupt and that file permission was untouched. We did this first since we didn't at the time know about the security fix that caused this problem. The system/application itself has not been touched after the security fix that caused this (after 14th).

    After we found about the erroneously security fix (googling to find this page) and to be 100% sure did (one can not always be certain) did we do the mentioned reproducable case with a new database file to be sure that nothing else was causing this.

    We have not been rolling back or touched the access installations on any client at all actually. This since the problem was reported to us yesterday and the clients were already automatically updated to "working" build 14701.20262.

    I'm now wondering about the users/companies that have had the problem and resolved it: Have they rolled back or done anything before 14701.20262 is applied? As mentioned have we not touched it manually at all (yet).
    Note: I'm a software developer and my IT department handles the installations/configuration, but since they also didn't know about this until yesterday/20th have they not tried anything yet and not altered the system and its automatic updates.

    Yes, the new file "test" is opened exclusive by design. The file is however closed and then later opened on other clients after creation and problem exists. We are making sure that intial Access is closed that created the access db file.

    We have verified that all Access clients have the default opening setting is set to "shared". So that is untouched as well.

    Yes, we are sure that the Access file on the network share is only used by us. Pretty sure with the "old system" and 100% sure in the "new access file test".

    Yes, we can reproduce the problem on the same (updated) client with several access instances. Both with the original "old" system and with a new access database file.

    We have verified with several clients that the computers are rebooted after 14701.20262 is installed .

    Yes, I also really wish that the problem was fixed with version 14701.20262 for us since the users will be working over christmas (peak period) and we would like to have our christmas holiday as normal :) So its a bit frustrating that its reported to be fixed and working for many, but not for us.

    Regards,

    Sven

    Was this answer helpful?

    1 person found this answer helpful.
    0 comments No comments
  3. Anonymous
    2021-12-21T05:17:12+00:00

    Hi All

    We had the same problem with our system . . 20 + PCs with several that were updated causing a lockout.

    On Monday AUS time . . i did a windows update and everything went back to normal.

    So - if you still having an issue - maybe look for latest updates rather than doing any roll-backs.

    cheers for now

    Hope everyone has a great Xmas . . :-)

    PaulG

    Was this answer helpful?

    0 comments No comments
  4. Anonymous
    2021-12-21T07:09:27+00:00

    You should not have to do anything other than get the latest updated, which for Current Channel is 14701.20262. You do have to ensure that all instances of Access have been updated, but if you were using multiple instances on the same machine and still see the problem that must not be the problem for you.

    Can you confirm that the File version on your copy of acecore.dll is 16.0.14701.20262, just to make sure the update applied properly? (The path to this file should be C:\Program Files\Microsoft Office\root\vfs\ProgramFilesCommonX64\Microsoft Shared\OFFICE16, for 64-bit Office, or C:\Program Files (x86)\Microsoft Office\root\vfs\ProgramFilesCommonX86\Microsoft Shared\OFFICE16 for 32-bit Office)

    If this is urgent for you, you should be able to roll back to the previous version (Version 2110), temporarily.

    Was this answer helpful?

    0 comments No comments
  5. Anonymous
    2021-12-21T08:48:57+00:00

    Thanks for your reply.
    Ok. No need other then to make sure that 14701.20262 is installed. Which it is.

    I have already examined that the process is running 16.0.14701.20262 (C:\Program Files\Microsoft Office\root\Office16\MSACCESS.EXE) and it's from 19th dec.

    I have now examined acecore.dll (C:\Program Files\Microsoft Office\root\vfs\ProgramFilesCommonX64\Microsoft Shared\OFFICE16)

    and it's also 16.0.14701.20262.

    In that folder are the following also files updated on 19th dec:
    csi.dll, (acecore.dll), mso.dll, fltldr.exe, Mso50win32client.dll, Mso40UIwin32client.dll, Mso30win32client.dll, Mso20win32client.dll, OLicenseHeartbeat.exe, msowercrash.dll, msoshext.dll and Mso98win32client.dll.

    I have asked the IT department to roll back over christmas atleast, but they said it is updating automatically. I asked them if it is not possible to pause the updates. So I have put the immediate problem in their hands and I focus on to get it to work with 14701.20262.

    Unfortunatly do I not have any more ideas to try/test. (Other than ask IT to roll back, which I prefer to avoid for me to make sure 14701.20262 works)

    Was this answer helpful?

    0 comments No comments