Access Database is getting corrupt again and again

Wow!  That's interesting.  Thank you for sharing this. I will go back and check the application's queries to see if any of them fit this description.  Any clues are helpful.

We have several locations with their own MSAccess database on a server and 15-30+ simultaneous users connecting via a frontend MSAccess database.  It had been years without any such corruption until the end of 2018, when the corporation's IT began updating the window 10 computers with the 1803 version(s).  Dealt with the issue intermittently over a couple of months.  Was likewise hesitant to use the work around either on the server or the clients.

We were able to identify a combination of delete and append queries to the same table, back-to-back that would cause this issue.  After we rearranged the queries and/or entered some delay between such, we have not had the issue re-surface for weeks. 

Not sure if we are out of the woods yet, and still look forward to the "fix".  But for now, addressing this by adjusting such back to back delete/append queries, seems to be working.

SO, just another piece of the puzzle that might provide some insight.

Thanks for the insight, TQuasar! In your experience, does the corruption occur with consecutive appends as well, or only when there are consecutive appends and deletes? I imagine it would be difficult to reduce consecutive appends in a multi-user environment.

We have several locations with their own MSAccess database on a server and 15-30+ simultaneous users connecting via a frontend MSAccess database.  It had been years without any such corruption until the end of 2018, when the corporation's IT began updating the window 10 computers with the 1803 version(s).  Dealt with the issue intermittently over a couple of months.  Was likewise hesitant to use the work around either on the server or the clients.

We were able to identify a combination of delete and append queries to the same table, back-to-back that would cause this issue.  After we rearranged the queries and/or entered some delay between such, we have not had the issue re-surface for weeks. 

Not sure if we are out of the woods yet, and still look forward to the "fix".  But for now, addressing this by adjusting such back to back delete/append queries, seems to be working.

SO, just another piece of the puzzle that might provide some insight.

Yes, I agree. This Client side registry fix is the best resolution - it just needs to be applied to each CLIENT. Not sure why the "disable leasing" on the server side is still being touted as the only temporary fix on Microsoft's site - it is known to have side effects and does not always work. My understanding and experience is the client side registry fix always works and is very simple to apply.

Has anyone else tried this, and I mean having applied it to every workstation accessing the data,  and not have it work?

Windows Registry Editor Version 5.00[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters]"FileInfoCacheLifetime"=dword:00000000"FileNotFoundCacheLifetime"=dword:00000000"DirectoryCacheLifetime"=dword:00000000

I suggest trying it.

Balking, why?  It is on Microsoft's official website as the only workaround. What more do they need.  There's an issue, MS has official provided a workaround, ...

Don't get me wrong a year to address this is absurd!  Absolutely absurd, but the workaround has been around since the beginning and it does "resolve" the issue.  Beyond that, it's a waiting game.  Who knows, it could be another year.  Show management the official MS webpage and get them to get IT to implement it.  There's little else you, or anyone, can do.

Good luck.