"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: Most helpful
  1. Anonymous
    2022-01-07T06:10:09+00:00

    The latest KB (4484211) appears to have corrected the issue with allowing multiple users to open a database using the MS Access frontend, however, we have numerous Excel reports that contain OLEDB links (Microsoft.ACE.OLEDB.12.0) to the .mdb (or .accdb) file. These links are not able to be refreshed if the database is opened, getting the same "File in use" error. Also, the database is closed and a user does happen to refresh one of these reports, the database can then only be opened in Read-Only mode until the Excel file is closed. This problem also exists now when everything is stored on a local hard-drive, not just on a network resource.

    Has anyone else experienced these or similar issues?

    JP

    There will be an updated patch soon that should address this issue as well.

    Was this answer helpful?

    1 person found this answer helpful.
    0 comments No comments
  2. Anonymous
    2021-12-21T15:41:24+00:00

    Without the IT knowledge about todays fileserversystems (I left the IT side of things 25+ years ago) do I think its the same I experience with greater descriptions so please check Philipps post Microsoft :)

    I have now also tried to link applikation file to database file (BE) using UNC and that makes no difference. Same problem.

    Was this answer helpful?

    1 person found this answer helpful.
    0 comments No comments
  3. Anonymous
    2021-12-21T14:31:48+00:00

    Same problem here.

    All clients updated to 16.0.14701.20262. Problem still persists.

    Lock files are left with 0 bytes.

    Was this answer helpful?

    1 person found this answer helpful.
    0 comments No comments
  4. Anonymous
    2021-12-21T14:00:14+00:00

    The problem is that it isn't just KB500299. It depends on your version of Access. There are different KBs and build numbers that all cause this issues. So it's a PC by PC situation.

    Furthermore, there are now multiple reports that the latest 'fix' doesn't work in all cases. Beyond which there isn't, yet, a fix for all versions either.

    I've been trying to keep me article up-to-date:

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

    Was this answer helpful?

    1 person found this answer helpful.
    0 comments No comments
  5. Anonymous
    2021-12-21T10:06:24+00:00

    I can't see any evidence, that 8.3-Names are involved.

    regarding the path to the database: The DB is located on a network-share. This share is published via dfs. On the fileserver it is located on a ntfs-volume with activated shadow-versions and activated deduplication. As far as I know, are in a technical view hard-links and the deduplication-feature is basically the same?

    Regarding the laccdb-files: currently I can't reproduce it. All the files are removed, if the last user leaves the database. But as far I remember: Yes, after deletion, the files where created when first user opens ist

    Was this answer helpful?

    1 person found this answer helpful.
    0 comments No comments