"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-21T15:09:46+00:00

    I've read somewhere else, that using UNC instead of mapped drives could solve the issue.

    I can't confirm this for my Environment: If I want to access via UNC onto an already opened database with Access Version 13801.21092 (2102 SemiAnnual), I get the same error :-(

    According to Sven Tegelmos investigations I've tried some different fileshares (all with UNC-Access):

    • Our regular Fileserver, share as DFS-Namespace as above, volume with deduplication (our standard, as described above)--> Don't work
    • Same Fileserver, share as DFS-Namespace as above, but volume with no deduplication --> Don't work
    • Same Fileserver, share as "regular" Share, volume with deduplication --> works!
    • Same Fileserver, share as "regular" Share, but volume with no deduplication --> works!
    • Share on Win10 --> works!

    It seems to me, that the way of sharing the database causes the issue.

    Was this answer helpful?

    6 people found this answer helpful.
    0 comments
  2. Anonymous
    2021-12-23T13:24:33+00:00

    For Office 2016 restoring de file ACECORE.DLL with the previous version 16.0.5239.1000 (2021/10/13) did the trick.

    I know that its not a good practice to mess with .dll's, but its the end of the year and people need to work.

    Merry Xmas

    Was this answer helpful?

    5 people found this answer helpful.
    0 comments
  3. Anonymous
    2021-12-14T20:04:18+00:00

    There are numerous reports about lock file issue sure to Patch Tuesday's update.

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

    Rolling back the update appears to currently be the only fix.

    Was this answer helpful?

    5 people found this answer helpful.
    0 comments
  4. Anonymous
    2021-12-23T11:07:01+00:00

    Ok. Some new information in my case. (Stull using "working" 16.0.14701.20262)

    At first apperience have we made it to work by using UNC connected directly to fileserver share.
    Application file is linked to Backend database file with UNC paths to share.
    The applications file (which is also on fileserver in our case) must also be opened from UNC (so mapped letter in file explorer does not work).

    This could be a work around until update is coming, but...

    Unfortunatly did I discover that even if running with UNC directly to shares doesn't "pessmistic row record locking" work. It uses optmistisk locking. Doesn't matter if set in Offfice settings, in every Form och using VBA Application.SetOption "Use Row Level Locking", True.

    You could argue against pessmistic locking, but our users has that as a requirement. The main/first reason that we have Access as back end instead of SQL server.

    So work around does not work and since this is the case do I fear that we have higher chance of getting uglier locking/data update problems which might cause more severe errors like corrupt database file etc.

    So be warned if you are trying the "UNC to direct shares" work around. It might have/cause none obvious faults.

    Regards,

    Sven

    Was this answer helpful?

    4 people found this answer helpful.
    0 comments
  5. 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