"Could not lock file" with Access build 14701.20248

To be clear: We have an "old" system with split frontend and backend database. (Application file is readonly). Starting yesterday (monday 20th) did several users report the problem in that system. Yesterday did the users say that it was working last week, but that might be due to the fact that only one user was using at a time. We can not verify that.

First did we verify that nothing was corrupt and that file permission was untouched. We did this first since we didn't at the time know about the security fix that caused this problem. The system/application itself has not been touched after the security fix that caused this (after 14th).

After we found about the erroneously security fix (googling to find this page) and to be 100% sure did (one can not always be certain) did we do the mentioned reproducable case with a new database file to be sure that nothing else was causing this.

We have not been rolling back or touched the access installations on any client at all actually. This since the problem was reported to us yesterday and the clients were already automatically updated to "working" build 14701.20262.

I'm now wondering about the users/companies that have had the problem and resolved it: Have they rolled back or done anything before 14701.20262 is applied? As mentioned have we not touched it manually at all (yet).
Note: I'm a software developer and my IT department handles the installations/configuration, but since they also didn't know about this until yesterday/20th have they not tried anything yet and not altered the system and its automatic updates.

Yes, the new file "test" is opened exclusive by design. The file is however closed and then later opened on other clients after creation and problem exists. We are making sure that intial Access is closed that created the access db file.

We have verified that all Access clients have the default opening setting is set to "shared". So that is untouched as well.

Yes, we are sure that the Access file on the network share is only used by us. Pretty sure with the "old system" and 100% sure in the "new access file test".

Yes, we can reproduce the problem on the same (updated) client with several access instances. Both with the original "old" system and with a new access database file.

We have verified with several clients that the computers are rebooted after 14701.20262 is installed .

Yes, I also really wish that the problem was fixed with version 14701.20262 for us since the users will be working over christmas (peak period) and we would like to have our christmas holiday as normal :) So its a bit frustrating that its reported to be fixed and working for many, but not for us.

Regards,

Sven

When will the MSI version be fixed? Is only the Click2Run version fixed now?

From MSFT:

New builds with the fix have started rolling out for some channels:

Current Channel: 16.13801.21092

Current Channel (Preview): 16.0.14729.20170

Semi-Annual Channel (Preview): 16.0.14326.20272

Semi-Annual Channel: 16.0.13801.21092

Semi-Annual Channel (Extended): 16.0.13127.21846

For anyone who has seen the issue on one of these channels, if you have the opportunity, please Update Now (it may not happen automatically) to get the updated version and validate that it addresses the issue.

@TylerWilliams_14

Check George's link as it covers the subject and provides the workaround (hint: rollback/uninstall the latest update).

Similar issue myself as I attempted to even relocate the back end into another shared location but it acted as if my URL for the location was incorrect or did not exist. Hoping to get a real resolution soon as rolling back the update isn't seeming like viable option for us.