"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: Newest
Most helpful Newest Oldest
  1. Anonymous
    2022-01-13T06:52:14+00:00

    We have now updated to Version 2112, build 14729.20248.

    This fixes the immediate "Could not lock file" problem, even on DFS file servers. It has cause the users to work on one machine for long and loosing precious time. Good its solved.

    However does two problem exists:

    1. The pessimsitic locking does not work. It works for single user/pc and multiple instances, but not for multiple users/machines. Then onlt optimisic occors (sam applikation with FE+BE). This with the original system on DFS that is untouched and pessimstic locking was working prior to all this.
    2. Simular to what is described earlier that Excel with OleDB links to Access does not refresh:
      With a BE+FE system and you move or update the BE location does it not work. Update location with Link manager in Access and the running the application (just opening forms) gives "Databas in use" errors. Also does it take longer to open some forms.
      Something is not updating correctly. Unfortunatly does the error occor for some forms and for some not all the time. 
      It can, with some effort and retries, be handled by opening all forms in the FE after relinking. Saving them all again. Compact and repair application file, but it feels really uncertain if it works afterwards anyhow.

    First problem is bad, but we handle it. The second is worse since now is it really uncertain if the system works if you do some development in the FE/application file and want to work with a development/testing BE (relinking is neeeded).

    Was this answer helpful?

    0 comments
  2. 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
  3. Anonymous
    2022-01-05T21:01:02+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

    Was this answer helpful?

    0 comments
  4. 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
  5. 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