Access Database is getting corrupt again and again

Our experience.  We have struggled with this issue for several weeks.  There are over 50 Windows 10 64 bit clients on the network as well as several Windows 7 machines.  The client machines communicate with the back end residing on a Windows 2012 server.

The Access application was enhanced to track user login/logout activity and an audit trail to report on detailed transaction activity.  

The recommended workaround was applied to the server and two of the problematic Windows 10 machines.  This appeared to resolve the matter but after a few days the database crashed once again.  A review of the login/logout activity indicated another user on a Windows 10 client missing  the recommended workaround opened the database.  Four seconds later a user on one of the stable Windows 10 machines; who was already logged in; attempted to run a routine that utilized an update, append and delete query in rapid succession.  The back end was once again corrupted.

The IT department was encouraged two weeks ago to apply the registry fix to all client machines that had not had the workaround applied and to confirm updates were current.  The application has run smoothly since that time.

Question:  Is the standard "unrecognized database format" message raised by Access related strictly to the back end database or could it be that it is the lock file (.laccdb) that is the root of the problem?  Is it possible the lock file is raising the error message and the back end is not actually corrupt?  We have noted after a crash the .laccdb has to be manually deleted before a repair can be run on the back end but have not found any missing data in the repaired back end.

Yes, the .laccdb appears to be the problem.  I can never seem to delete the damaged .laccdb file (the most recent case has had garbage characters in it).  Can you give me some tips on that?

Thanks for the detailed description that identifies unequivocally where the problem lies. Surely this is enough for Microsoft to work on to get a solution that does not involve making registry changes that can have undesirable side effects on some systems and cannot be implemented on large sites that have servers shared across many departments where the IT department, understandably,  do not want to risk compromising other functionality. 

I can confirm that in all cases I have seen there is actually no corruption in the database itself - it is just in a state that is not recognised by the front ends. Typically corruption results in missing indexes and broken relationships but i have never seen this. The fix is to open the database with the full version of Access, agree to the repair, and the database is accessible again. I suspect a bit has been flicked, perhaps in the .laccd as you suggest)

The fix is so simple that I have explained this procedure to customers so they can "fit" it themselves, but it is not a good look and may result in them eventually using it when it is not appropriate and there is a genuine corruption!!

Spot on!  I had another site this week that had to be patched and the .laccdb file was persistent and contained garbage characters each time.  At least give us a way to easily delete persistent locking files.

Thanks for the detailed description that identifies unequivocally where the problem lies. Surely this is enough for Microsoft to work on to get a solution that does not involve making registry changes that can have undesirable side effects on some systems and cannot be implemented on large sites that have servers shared across many departments where the IT department, understandably,  do not want to risk compromising other functionality. 

I can confirm that in all cases I have seen there is actually no corruption in the database itself - it is just in a state that is not recognised by the front ends. Typically corruption results in missing indexes and broken relationships but i have never seen this. The fix is to open the database with the full version of Access, agree to the repair, and the database is accessible again. I suspect a bit has been flicked, perhaps in the .laccd as you suggest)

The fix is so simple that I have explained this procedure to customers so they can "fit" it themselves, but it is not a good look and may result in them eventually using it when it is not appropriate and there is a genuine corruption!!

Our experience.  We have struggled with this issue for several weeks.  There are over 50 Windows 10 64 bit clients on the network as well as several Windows 7 machines.  The client machines communicate with the back end residing on a Windows 2012 server.

The Access application was enhanced to track user login/logout activity and an audit trail to report on detailed transaction activity.  

The recommended workaround was applied to the server and two of the problematic Windows 10 machines.  This appeared to resolve the matter but after a few days the database crashed once again.  A review of the login/logout activity indicated another user on a Windows 10 client missing  the recommended workaround opened the database.  Four seconds later a user on one of the stable Windows 10 machines; who was already logged in; attempted to run a routine that utilized an update, append and delete query in rapid succession.  The back end was once again corrupted.

The IT department was encouraged two weeks ago to apply the registry fix to all client machines that had not had the workaround applied and to confirm updates were current.  The application has run smoothly since that time.

Question:  Is the standard "unrecognized database format" message raised by Access related strictly to the back end database or could it be that it is the lock file (.laccdb) that is the root of the problem?  Is it possible the lock file is raising the error message and the back end is not actually corrupt?  We have noted after a crash the .laccdb has to be manually deleted before a repair can be run on the back end but have not found any missing data in the repaired back end.