Access Database is getting corrupt again and again

Thanks for that. So in your experience drive remapping wasn't an issue that had to be addressed as long as a server reboot immediately followed the reg fix. From reading above.....unless I've misunderstood...... it seems this isn't always the case. Can anyone else confirm one way or the other?

Hi

in my experience on multiple sites, the server fix was the least disruptive. We applied the fix when all users were logged off and also rebooted the server after restarting the services (as per Microsoft’s instructions). On one site, the admin tried to use his PC before the server reboot and panicked at the loss of mapped drives etc. However, after the server reboot, he was able to login and all was well. 

Obviously, if other experiences are different, then this is a concern, but we have enjoyed a 100% success with server-side fix only, with the caveat of a server reboot before attempting client login/connection. 

Hope this helps.

From the recent discussion above it would appear that applying the official MS fix on the server is likely to create considerable IT waves with mapped drives being lost and presumably having to be remapped. I'm assuming that the remapping would have to be done on all client machines connected to the server.......not a small job if there are many users.

In light of that, it seems that the fix that has been employed successfully on the client machines only may be the less painful path which wouldn't introduce the problems with mapped drives or involve the IT department.

The downside I can see of the client side fix is that one new or re-imaged client machine that hasn't had the fix employed would be enough to break the database.

I'm trying to look at all angles regarding a database I'll be installing shortly for a new client and what method will cause the least disruption.

Are you talking about the Disable Leasing fix or the other one?

I did the Disabled Leasing as WayneAprato recommended a page or 2 back... to the client side of things.  I didn't want to risk doing this on my main production file server.  It worked just fine and my users have not had the issue return.

First and foremost, after a discussion yesterday i found out that the wording on the workaround page was incorrect.  The registry Jack workaround only needs to be applied to the back-end server.  It does NOT need to be applied to each individual user's PC. (Would have been nice to know that for the past year!)

The registry hack can be found on Microsoft's page on the subject,https://support.office.com/en-us/article/access-reports-that-databases-are-in-an-inconsistent-state--7ec975da-f7a9-4414-a306-d3a7c422dc1d?ui=en-US&rs=en-US&ad=US, and yes you could create a reg file to deploy it instead of running it directly in the command prompt.

Lastly, as reported above by others, when i applied the fix, i lost all the mapped drives.  Fun times were had by all.

Daniel, are you in contact with Microsoft by any chance? It's funny that you posted this and their documentation was updated today. Do you happen to know what is Microsoft's stance on the other suggested fix? Do you know what it actually does?

"FileInfoCacheLifetime"=dword:00000000

"FileNotFoundCacheLifetime"=dword:00000000

"DirectoryCacheLifetime"=dword:00000000