Access Database is getting corrupt again and again

No, I only applied the registry fix to the Server 2012 and this stopped the corruptions on the client PCs.

Thanks. So it was the server only? You didn't apply the workaround on the workstations?

Did you see any negative impact on server performance? This seems to vary according to different accounts from people who have employed the workaround. Also....how big is the organisation......number of workstations?

I have not noticed any slow down on the client PCs (Windows 10 v1803/v1809).  That was a relief for me after reading the potential speed issue.  I have noticed when working on the server directly that there seems to be a slight slow down in performance, but nothing to complain about.  Also, we are only ever logged on the Server occasionally for server maintenance etc.  The monthly server updates seem to install quickly enough and the server restarts are no longer than would be expected... Having said that, I am usually restarting the server remotely of an evening and always wait 5 minutes after the 'ping' shows the server has successfully restarted, to allow for services to fully restart.  I hope that helps.

Thanks Graeme.

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.