Access Database is getting corrupt again and again

Hi,

Really, really, don't take my experience as anywhere near to being properly tested (my disclaimer) but as per a reply I did on the 18th November I have found 1809 to work.

I tested on two different PC's that previously did cause the corruption and with 1809 is was not.

However I have not fully integrated into my LAN as I found the workaround OK for me, small 3 PC LAN and left alone on 1803.

Basically you never know what 1809 will introduce as possible NEW bugs so felt best leave alone for a while but I would be fairly confident is would work but as no one else seemed to have said this I am more than a little cautious although since pulling the update you have had to force the 1809 update and does not seem like many are getting it automatically.

I suspect something was done with networking as with 1809 I found that other PC's on the lan were not always visible in file explorer. Age old problem with often a variety of causes so could be unrelated but on 1809 the only way I could see some other PC's on the lan was to directly type \HomePC\My Docs .... etc.

What patch? To my knowledge Microsoft has yet to even identify the issue, little alone provide a fix. According to the official page on the subject (last updated in June!) It is still in workaround status, see https://support.office.com/en-us/article/access-reports-that-databases-are-in-an-inconsistent-state--7ec975da-f7a9-4414-a306-d3a7c422dc1d

As for the slowdown you reported after applying the registry hack, your not alone, many have stated the same things.  Sadly, there doesn't seem to be any solution to that issue either.

I have applied the DisableLeasing modification and it works but it is slowing down considerably the network access. 

Some part of my application are almost not usable at all now while it was working perfectly fine before the 1803 update.

Do you know if the patch has been applied to the 1809 update, I would like to apply it and then get rid of the DisableLeasing correction?

Thank you

S.

Yes; I have had difficulty deleting the .laccdb file a few times.  I believe it is due to another problematic Windows 10 machine which appears to have the file in use and will not allow it to be deleted.  As I mentioned previously the log and transaction reports always indicate there is a client machine involved that has not had the registry fix applied.  At least I am able to quickly ID the offending client machine now.  The .laccdb is 0 KB and appears to be corrupt.  In a few instances I have found that if I cold boot the offending client machine it appears to release the .laccdb.  However; most of the time I can delete the lock file.  

On a least one occasion I had to enlist the help of the IT guys who have administrative rights on the network to kill the lock file.  In all instances once the lock is gone the repair runs uneventfully but there never seems to be missing or corrupt data in the repaired back end database.  It appears to me the focus should be on the .laccdb and what changes Microsoft made in the 1803 release.

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?