Access Database is getting corrupt again and again

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.

Hi Shane,

Many thanks for the update, it is much appreciated, and somewhat reassuring to know that you are still actively working on it.

It would be really helpful, when dealing with frustrated users, for the date on the official bug report page to be updated at least monthly.

https://support.office.com/en-us/article/access-reports-that-databases-are-in-an-inconsistent-state-%ef%bb%bf-7ec975da-f7a9-4414-a306-d3a7c422dc1d currently has: Last Updated: Aug 14, 2019

So it gets increasingly difficult to persuade IT staff that this remains the up to date solution.

It does seem almost incredible that after all this time you are still unable to reproduce such a widespread issue. Can this information also be added to the official page please? As well as helping to explain the long delay, it might motivate more users to help find out how to reproduce it. 

David Nye

http://www.dnye.co.uk/

Thanks Karl, you are absolutely right. I was referring to certain scenarios only, and should have said so.