"Could not lock file" with Access build 14701.20248

Thanks for your reply.
Ok. No need other then to make sure that 14701.20262 is installed. Which it is.

I have already examined that the process is running 16.0.14701.20262 (C:\Program Files\Microsoft Office\root\Office16\MSACCESS.EXE) and it's from 19th dec.

I have now examined acecore.dll (C:\Program Files\Microsoft Office\root\vfs\ProgramFilesCommonX64\Microsoft Shared\OFFICE16)

and it's also 16.0.14701.20262.

In that folder are the following also files updated on 19th dec:
csi.dll, (acecore.dll), mso.dll, fltldr.exe, Mso50win32client.dll, Mso40UIwin32client.dll, Mso30win32client.dll, Mso20win32client.dll, OLicenseHeartbeat.exe, msowercrash.dll, msoshext.dll and Mso98win32client.dll.

I have asked the IT department to roll back over christmas atleast, but they said it is updating automatically. I asked them if it is not possible to pause the updates. So I have put the immediate problem in their hands and I focus on to get it to work with 14701.20262.

Unfortunatly do I not have any more ideas to try/test. (Other than ask IT to roll back, which I prefer to avoid for me to make sure 14701.20262 works)

You should not have to do anything other than get the latest updated, which for Current Channel is 14701.20262. You do have to ensure that all instances of Access have been updated, but if you were using multiple instances on the same machine and still see the problem that must not be the problem for you.

Can you confirm that the File version on your copy of acecore.dll is 16.0.14701.20262, just to make sure the update applied properly? (The path to this file should be C:\Program Files\Microsoft Office\root\vfs\ProgramFilesCommonX64\Microsoft Shared\OFFICE16, for 64-bit Office, or C:\Program Files (x86)\Microsoft Office\root\vfs\ProgramFilesCommonX86\Microsoft Shared\OFFICE16 for 32-bit Office)

If this is urgent for you, you should be able to roll back to the previous version (Version 2110), temporarily.

Hi All

We had the same problem with our system . . 20 + PCs with several that were updated causing a lockout.

On Monday AUS time . . i did a windows update and everything went back to normal.

So - if you still having an issue - maybe look for latest updates rather than doing any roll-backs.

cheers for now

Hope everyone has a great Xmas . . :-)

PaulG

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

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