Access Database is getting corrupt again and again

I discovered that if the database isn't allowed to compact and compare (after sitting idle ...usually over night) we are guaranteed issues the next day. I added code to close the users databases at the end of their work day...resulting in much better performance now.

If you can create a sample database and sequence of steps and provide that to Microsoft, that would be a big help to them I think. Shane from Microsoft has contributed to this topic and I believe has said they are working on this problem, but the main thing they had trouble with was recreating the problem. Ultimately this is something that has to be fixed by Microsoft and not with the suggested server workaround. Some here suggest abandoning Access which I understand. However, I have a very complex and large Access application that has evolved over 20 years. It would take me years to rewrite it with other technologies. I hope Microsoft does not just give up on this as it has been devastating to many customers, end users and developers alike.

There is another client based Windows 10 registry change that is working for me so far (I would be out of business otherwise) that has been presented many times in this thread that you might want to check out. It does not require a server change, but It has been to done to ALL the Windows 10 PCs that use the application.

Please Microsoft fix this and don't give up on Access. Millions of database users still rely on it. I am glad it is still part of the current Office 365 offerings. I wish it was taken more seriously by Microsoft so the reputation of Access (and the users and developers reputations that use it) could be restored.

We did not want to use the work around for various reasons, and have been able to reduce the occurrence of the inconsistent issue.  With a new server about to replace an older one have considered using the work around, but wanted to do further testing.  Please see below.

Updates:

After some thorough testing where I was able to replicate the issue repeatedly I arrived at these observations.

We have a frontend-backend database which each morning is updated in such a way as to empty and re-populate and edit many tables on the backend. For years this was performed with or without multiple users logged in and there was never an inconsistent error. But after the Windows Update 1803, it was often at this point that there would be an inconsistent database error if there was any other user logged into the database. But it was not all the time, which seemed unusual, until some further testing was done. Now I can report the following conclusions.

1. When the user who will initiate the morning updates is the first one into the database, the procedure is accomplished without issue. Note: If other users were logged into the database after the first user, the procedure will still work.
2. If there is already someone logged in and then the user logs in who performs the updates, the inconsistent error always appears when the procedure is run.
3. The procedure is a sequence of multiple queries and macros with embedded queries. I could repeat the procedure under the same circumstances and the inconsistent issue would appear with the same query.
4. If I removed the query, the issue would still appear but later in the procedure. I could then remove that query and the issue would appear again later in the procedure with another subsequent query.
5. I broke the procedure up into three sub-procedures and the first sub-procedure would have no issue.
   1. The second sub-procedure would then produce the issue.
   2. If I logged out the other user who had logged in first, and then logged the user back in, and then initiated the second sub-procedure it would complete itself without issue.
   3. I could repeat step b with the third procedure without issue.

So, I hope this might provide some insight to someone who has more experience than me regarding Access and maybe come up with a way to "reset" something after each sub-procedure in such a way that I could have them all work without having to have other users logged out.  (We usually have everyone wait to get in the database until after the morning updates, but on occasion someone will already be logged in and then we have the issue.)

PS: One strange exception to point 1., if I used the ldb viewer to see which computers were logged in, and then closed the ldb viewer and then launched the procedure, it would fail. I have not taken the time to confirm this but will do so and provide additional feedback.

Notes: Backend Access2000 .mdb ; Frontend Access 2007 .accde ; Windows 10 with Access 2013. Have three different locations which use the database as indicated each with between 15 and 30 concurrent users.

Hi Carlos,

Our Access database will be going away in the near future, so it wasn't worth the effort trying it convert it to SQL Server. I have been waiting to have our IT Support to implement the Disable Registry hack fix to our BE host server, but they move at their own speed.

I came across a simple fix by accident: Created a subfolder below where my BE database file was, move the db file to the new subfolder then relink my FE to the BE tables' new location. That was Monday, and so far, no database corruption issues. I'm not sure why, but I'm not complaining. Gives me some breathing room until IT Support applies the fix.

George