"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

50 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Anonymous
    2021-12-21T09:35:06+00:00

    I can confirm that in my case I did roll back the workstation experiencing the problem from 14701.20248 to 14701.20226. 

    I instructed the other users to disable Office Updates on all other workstations, which were nearly all still on 14701.20226.  

    One user did this too late, automatically updated to 14701.20248 and experienced the same locking problem. I also rolled this system back to 14701.20226.

    After the fix was released, I updated the original problem workstation to 14701.20262 by 

    deleting the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\Configuration\UpdateToVersion value from the registry and running Update Now for Office Updates. That system then worked fine with the other users still on 14701.20226.

    I instructed the other users to re-enable Office Updates, The system is now running OK with a mixture of builds:

    • 2 users that have been roll back from 14701.20248 to 14701.20226 and then updated to 14701.20262
    • 4 users that skipped from 14701.20226 to 14701.20262 with no ro9lling back
    • 9 users that are still on 14701.20226 because they have not yet re-enabled Office Updates or because the latest update has not yet been applied

    The system has been running with this mix for couple of days now with no issues.

    Kind regards

    Neil

    Was this answer helpful?

    0 comments
  2. Anonymous
    2021-12-21T09:12:33+00:00

    Can you determine if you are using 8.3 names for file names or directory paths?

    Are there any symlinks, juntions, or hard links involved in the path to your database?

    If you delete the .laccdb file before opening the database, does the .laccdb file get created when the first user opens it?

    Was this answer helpful?

    0 comments
  3. Anonymous
    2021-12-21T09:08:29+00:00

    I would like to get a little more information outside the public form to see if I can help.

    To do that, can you post some feedback using send-a-frown in Access, with your issue, and the keyword "lockfileissue". Make sure to check the box to include your email address when you submit the feedback.

    I'll respond to that feedback directly.

    Was this answer helpful?

    0 comments
  4. Anonymous
    2021-12-21T09:06:40+00:00

    hi, we work with front/back access application where the back end is on a shared drive.

    Problem is not solved. Updated to the latest version. acecore.dll is 16.0.14701.20262

    Was this answer helpful?

    0 comments
  5. Anonymous
    2021-12-21T09:06:18+00:00

    I can also confirm that lock-files remains with 0 bytes size after closing Access.

    We have 16.0.14701.20262 though.

    // Sven

    Was this answer helpful?

    0 comments