"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: Newest
  1. Anonymous
    2021-12-21T13:08:47+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

    Since this MSI's don't required a reboot, its almost impossible to make 100's of users to do that. We end up with a mixed situation and the problem not fixed.

    Please make the fix to force a reboot.

    PS: we using WSUS

    Was this answer helpful?

    0 comments No comments
  2. Anonymous
    2021-12-21T13:01:12+00:00

    Ok. Some new information in my case.

    First summarize our status:

    As said earlier do we have updated clients to 16.0.14701.20262.

    We have an old (working before last weeks security patch problems) application that only one can be using at a time.

    We can reproduce the problem with new access file so nothing says that something is wrong with the old system.

    Now:

    Have I tested to reproduce the problem on an other server (actually a webb test server that I as I software developer have permission to create file shares on) and it works there! I can open the file in two access instances without "File i nuse"-error. The lock file is also removed after last instance is closed.

    So the security patch has caused problem related to our environment that is NOT fixed in 16.0.14701.20262. So to me does it seem to be a combination with fileserver/network/configuration and a patch that does not handle that.
    To be clear and repeat has it been working in our environment prior to last weeks security patch so I can not say something is wrong with fileserver.

    Since I'm not a IT profeissional is it difficult to say the difference between the filrserver used and the test share I did from our test server. I have passed the information to our IT, but I guess they will have it difficult to solve since the fileserver is what it is and have been for long prior to the security patch.

    Kind regards,

    Sven

    Was this answer helpful?

    0 comments No comments
  3. Anonymous
    2021-12-21T11:23:13+00:00

    That would be great, but I'mFeeling a bit stupid, but I do not know how to send-a-frown. Googling it says Help->feedback in the Office app, but I have no such option. Only "Contact support", but no option there to send feedback. Can not find it under File either. Has it been removed by and IT policy? Seems strange to do that.

    Was this answer helpful?

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