Access Database is getting corrupt again and again

Well said.  Precisely why I cannot migrate the back-end to SQL Server.  I have no interest in getting approximately 50 different IT departments involved in something THEY don't want to know about.  Also, keeping the back-end in Access lets me provide fast support as I can easily obtain copies of their data files and diagnose problems within minutes.

I'm not sure if it helps, but the database I am using was built entirely using the Access 2016 active "Create" feature, not as a VB scripted database.

Mr Groff,

I'm a bit late jumping on this trail, but I noticed your requests for information on how to replicate the failure have gone largely unanswered.  For my own part, the recent Security Patch uploaded at my place of business on/ around  November 15 has created a state whereby Access throws a "[filename] is corrupt" pop-up when executing any form of an Update Query. the flag triggers both when driven by a Macro and when the Query is run as a stand alone. The query pulls data when executing the "View" option, but fails out when using the "Run" exclamation point.

The data base I'm using has executed flawlessly since late July when it was first developed, and it appears to only be the "UPDATE QUERY" function at this time. Given my place of work, there is no option to back out the recent update. A "fix" would be greatly appreciated.

Hi Wayne,

The biggest problem with this issue is that we still don't have a way to reproduce the problem in a controlled environment.

Nobody has been able to give us a situation where it is "Do these steps", then "Database is corrupted".

We believe we understand the change in Windows that caused the increase in corrupted databases, and have been testing changes that we hope will alleviate the problem in production.  Initially, that will be for O365 Monthly Channel users.  It will not necessarily address all the issues, particularly in environments with users using different versions (if someone using Access 2016 corrupts the database, it may still be reported as corrupt when it is opened in Access365).

I am not suggesting this as a workaround, because I know it isn't a trivial transformation, but if this is causing you significant issues, it is worth considering using Access for the front end, and storing data in  SQL Server.

We will share more information when we have it, but I don't want to make promises we can't deliver on.

Thanks for the update, Shane. The registry workaround solved the issues that we had.

I have a suggestion for being able to reproduce this issue in a controlled environment:

• create a simple data entry style application in Access
• split the database into a front-end and a back-end located on a network share
• create several different virtual machines with automation to enter some random data into the system continuously, via a local copy of the front-end
• have a couple of the VM's editing the data that the other VM's entered as well

The corruption may not occur predictably at first, but with application and network logs, it may help narrow down the exact issue.