Lock File Problems with Access 16.0.13801.21086

Anonymous
2021-12-14T12:18:17+00:00

On 12/14/2021, SemiAnnual Enterprise channel updated to version 16.0.13801.21086. This is causing several strange behaviors in Microsoft Access. For example:

  1. Create a new Access database on a network drive or open an existing database from a network drive. Close it. The .laccdb file is not automatically deleted (even though no other users are in it).
  2. Use DAO to OpenDatabase for shared (non-exclusive) access. Error 3050 (“Could not lock file.”) is thrown and the database is not opened.
  3. Databases opened on a network drive appear to always be opened for exclusive access. Once one person has opened a database, others can't--even when opening for shared access.

Reverting to the prior version 16.0.13801.21050 fixes the problem.

This problem seems specific to databases located on a network share. For databases on a local machine, there is no issue.

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

98 answers

Sort by: Most helpful
  1. Anonymous
    2021-12-15T16:12:33+00:00

    Here is the fix that worked for me regarding the shared MSAccess database locked file issue. No MSOffice updates were listed in the "Installed Updates" Control Panel section. (Office 2016 Click2Run Version)

    1.  Close all MSOffice applications

    2.  At an elevated prompt, run the following (with quotes in the path)

    1. "C:\Program Files\Common Files\microsoft shared\ClickToRun\OfficeC2RClient.exe" /update USER displaylevel=True forceappshutdown=true updatetoversion=16.0.14701.20226

    4.  After completed, verify the version number has reverted to the 20226 version (Dec 3rd) listed under the Account settings of the MSOffice application.

    1. Temporarily "Disable Updates" from the MSOffice Account screen and verify your MSAccess database operation.

    Was this answer helpful?

    7 people found this answer helpful.
    0 comments No comments
  2. Anonymous
    2021-12-15T11:31:32+00:00

    You can now find all the information regarding this latest bug, including the workaround at

    https://www.devhut.net/access-lock-file-issues/

    Was this answer helpful?

    6 people found this answer helpful.
    0 comments No comments
  3. Anonymous
    2022-01-12T07:41:59+00:00

    Seriously? I have made the tests and I can confirm, it's fixed it only for 2108 (14326.20738) and not for 2102 (13801.21106)! This is outrageous, 2102 supposed to be stable channel, still supported, we have procedures on the production, we can't change Office version for thousands of users without testing the AddIns and any other Office dependent software. Why fixing only for one build and not the others?

    And why there are still no 2008 version? This version supposed to be supported until 8th of March 2022, is there a plan to release it? What is going on there?

    Was this answer helpful?

    5 people found this answer helpful.
    0 comments No comments
  4. Anonymous
    2021-12-23T17:30:43+00:00

    Even with the updated build, using DFS paths will prevent multi-user access. Fow now, you will have to use a direct network path to the database if you want to have multiple instances accessing the same database.

    Our organization has multiple MS Access databases shared via DFS. DFS being deployed as an enterprise solution to presenting file shares. This patch has been extremely disruptive with the 2nd patch not resolving the issue. How soon can we expect a full resolution?

    Was this answer helpful?

    5 people found this answer helpful.
    0 comments No comments
  5. Anonymous
    2021-12-15T11:21:29+00:00

    We have found the culprit for our problem!
    My team have found that the problem was in security update for MS office 2016 (KB5002099)

    After uninstall problem is solved

    Was this answer helpful?

    5 people found this answer helpful.
    0 comments No comments