Access Database is getting corrupt again and again

Please review https://github.com/MicrosoftDocs/windows-itpro-docs/issues/934 and apply registry settings to Windows 10 computers.  This has resolved all problems with MSAccess back-end database issues.

Bravo, Mark!  You have fully articulated the impact this is having.  I wonder if Microsoft realizes the sophistication of the applications that are developed under Access and how critical these applications are to government, business and data analysis.  It's not all Northwind.

We have a in house Point of Sale Access FE - BE application and have had many of the same issues as everyone else here. Our problem has not been nearly as severe as many others have been.

We only seem to have an issue first thing in the morning after doing a maintenance compact and repair, on either Fridays or the end of the month. I will open the BE DB and re-compact and then all seems fine for another week. I have tried several of the easier fixes to no avail. 4 weeks ago, I came across a link by WayneAprato on page 12 of this thread "https://github.com/MicrosoftDocs/windows-itpro-docs/issues/934" and decided it couldn't do any harm and tried it.

I have not had any lockups or slowdowns since applying the fix on the Win10 workstations.

 Here is the fix in the included thread.

Copy and save the following text to notepad and save it as "SMBCacheFix.reg" (with quotes)

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters]

"FileInfoCacheLifetime"=dword:00000000

"FileNotFoundCacheLifetime"=dword:00000000

"DirectoryCacheLifetime"=dword:00000000

I hope this will help others.

Great post Mark!

Fully agree on the credibility remark.  As if IT departments needed another excuse to not want to support Access in industry and then this!

Shane,

I appreciate that you are participating in this discussion and taking the brunt of our wrath. This is a very serious problem for Access developers as you can tell. I own a company that is based solely on a product developed in Access that uses a back-end database (accdb file) to hold the data which is most often shared on a Window 2008 or above server (mostly 2012 or above) or a Windows 10 (or earlier) workstation. We have thousands of customers and this has been devastating. Like everyone else, we started getting these errors last year with the Windows 10 1803 update. Subsequent Windows 10 updates have helped in some cases. The disable leasing change on the server seems to resolve the issue for most customers. Explaining that this was caused by a Microsoft Windows update (not our app) and offering the workaround only goes so far and my company has lost a lot of credibility because of this problem. Many companies will implement the disable leasing on the server without questioning it and do not experience noticeable performance problems. So that is the good news with this problem I suppose.

However, many companies get their IT people involved who are VERY reluctant to disable leasing on the entire server. In some cases where they make the change, some features or apps stop working and some companies experience performance issues. So, we lose A LOT of credibility with the IT world, leaving them thinking our application is old or obsolete. When the truth is that the SMB protocol is very much alive as is Microsoft Access (it is part of the latest Office Suites) and there are millions of Microsoft Access applications. This is not a small issue and many of Microsoft's end customers and loyal developers are losing time and money and getting extremely frustrated due to this problem. Even the customers who implement the fix experience lost time and effort, let alone the many who never even call and just deal with compacting and repairing as this can be done with a few clicks and most time repairs the file (but is still a major inconvenience and embarrassment).

I sincerely hope that Microsoft can recreate and solve this issue very soon for everyone's benefit. I hope that something is imminent as you seemed to indicate. That would be fantastic and if you could tell us anything more definitive we would appreciate it. I may have an alternative way to implement the disable leasing solution on the server and I am wondering if anyone has tried this or if this has merit. I just recently ran across this and am in the process of trying it with some of my customers. There is a Leasing Mode setting on the share name on the server that can be turned off via Powershell, without disabling it on the entire server. This would limit the scope and impact of the disable leasing change to just the users of our application and only when using our application. Here are the directions I recently sent to a few customers and I am awaiting the results. I would be interested in any feedback on this approach:

An alternative to disabling leasing on the entire Windows server is to disable leasing for just one folder

1. Create a new folder for the data file on the server and move the data file to this folder.
2. Share the new folder on the server and give it a share name (e.g., MyData).
3. Start Powershell as Administrator on the server.
4. Set the leasing mode for the new share to None with the following commands: 

    a. set-smbshare MyData -LeasingMode None 

    b. get-smbshare MyData | Format-List -Property *    (make sure Leasing Mode is set to None)

5. Restart the server to be sure the change is implemented (make sure everyone is disconnected first) 
6. Do the powershell command again to make sure leasing is still off (get-smbshare MyData | Format-List -Property *)
7. Make sure the front end database application on each client PC points to the new UNC path for the above shared area and data file.
8. As a precaution, rename the old data file so no one can open it with the old path to the original share.    

Note: To turn leasing back on if needed (in case of problems):

           set-smbshare MyData -LeasingMode Full            (then restart the server)

Let me know what you think! I am keeping my fingers crossed.

Mark Mauger

Quantum Software Solutions, Inc.