On 12/14/2021, SemiAnnual Enterprise channel updated to version 16.0.13801.21086. This is causing several strange behaviors in Microsoft Access. For example: Create a new Access database on a network drive or open an existing database from a network drive. Close it. The .laccdb file is not automatically deleted (even though no other users are in it). Use DAO to OpenDatabase for shared (non-exclusive) access. Error 3050 (“Could not lock file.”) is thrown and the database is not opened. Databases opened on a network drive appear to always be opened for exclusive access. Once one person has opened a database, others can't--even when opening for shared access. Reverting to the prior version 16.0.13801.21050 fixes the problem. This problem seems specific to databases located on a network share. For databases on a local machine, there is no issue.

I reported it to Microsoft earlier this morning, waiting to hear back. Use the application feedback command within Access to send in your comments to the Dev Team. I now see another similar thread in this forum with similar symptoms https://answers.microsoft.com/en-us/msoffice/forum/all/this-file-is-in-use-error-received-with-build/4a406c85-6d06-4601-905c-12aa9930d343

It's amazing. We're seeing a new wave of people just encountering the bug this week. Apparently some organizations were relatively inactive over the second half of December and therefore didn't encounter this bug. Coming back to work after the holidays, they're encountering it now. As Daniel says, sometimes the expedient approach really does make sense. It's not pretty, it's maddening even. But if the choice is getting your work done, or hanging fire for a fix that may not be available in the short term, then expedient it is. Roll back the updates. And perhaps it's not unwise to start the process of protecting your future ability to manage your data by not putting all your eggs in one basket.

Even with the updated build, using DFS paths will prevent multi-user access. Fow now, you will have to use a direct network path to the database if you want to have multiple instances accessing the same database. Thanks for the clarification Shane. Is there a time frame you're aware of within which this might be sorted? How long is "for now"? I will let them know about this and we'll work something out.

The fix is available now for MEC: Monthly Enterprise Channel Version 2110, build 14527.20344

Further ... when attempting to open a database already opened by a prior user (shared or exclusive makes no difference), the second user's attempt fails, but DOES result in the second user deleting the lock file. Subsequently when the first user closes and reopens the database, no lock file is created (at least not in the same location as the database), yet the second user still CANNOT open the database - even though no lock file exists. This is unexpected. Greg

Lock File Problems with Access 16.0.13801.21086

Anonymous

On 12/14/2021, SemiAnnual Enterprise channel updated to version 16.0.13801.21086. This is causing several strange behaviors in Microsoft Access. For example:

Create a new Access database on a network drive or open an existing database from a network drive. Close it. The .laccdb file is not automatically deleted (even though no other users are in it).
Use DAO to OpenDatabase for shared (non-exclusive) access. Error 3050 (“Could not lock file.”) is thrown and the database is not opened.
Databases opened on a network drive appear to always be opened for exclusive access. Once one person has opened a database, others can't--even when opening for shared access.

Reverting to the prior version 16.0.13801.21050 fixes the problem.

This problem seems specific to databases located on a network share. For databases on a local machine, there is no issue.

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

98 answers

Anonymous

2021-12-14T18:36:30+00:00

I reported it to Microsoft earlier this morning, waiting to hear back.

Use the application feedback command within Access to send in your comments to the Dev Team.

I now see another similar thread in this forum with similar symptoms

https://answers.microsoft.com/en-us/msoffice/forum/all/this-file-is-in-use-error-received-with-build/4a406c85-6d06-4601-905c-12aa9930d343
Was this answer helpful?

4 people found this answer helpful.

0 comments No comments
George Hepworth 23,120 Reputation points Volunteer Moderator

2022-01-04T16:45:39+00:00

It's amazing. We're seeing a new wave of people just encountering the bug this week. Apparently some organizations were relatively inactive over the second half of December and therefore didn't encounter this bug. Coming back to work after the holidays, they're encountering it now.

As Daniel says, sometimes the expedient approach really does make sense. It's not pretty, it's maddening even. But if the choice is getting your work done, or hanging fire for a fix that may not be available in the short term, then expedient it is. Roll back the updates.

And perhaps it's not unwise to start the process of protecting your future ability to manage your data by not putting all your eggs in one basket.
Was this answer helpful?

2 people found this answer helpful.

0 comments No comments
Anonymous

2021-12-23T13:51:12+00:00

Even with the updated build, using DFS paths will prevent multi-user access. Fow now, you will have to use a direct network path to the database if you want to have multiple instances accessing the same database.

Thanks for the clarification Shane. Is there a time frame you're aware of within which this might be sorted? How long is "for now"? I will let them know about this and we'll work something out.
Was this answer helpful?

2 people found this answer helpful.

0 comments No comments
Anonymous

2021-12-18T05:39:37+00:00
The fix is available now for MEC:
- Monthly Enterprise Channel Version 2110, build 14527.20344
Was this answer helpful?

2 people found this answer helpful.

0 comments No comments
Anonymous

2021-12-15T23:14:04+00:00

Further ... when attempting to open a database already opened by a prior user (shared or exclusive makes no difference), the second user's attempt fails, but DOES result in the second user deleting the lock file.

Subsequently when the first user closes and reopens the database, no lock file is created (at least not in the same location as the database), yet the second user still CANNOT open the database - even though no lock file exists.

This is unexpected.

Greg
Was this answer helpful?

2 people found this answer helpful.

0 comments No comments