Access Database is getting corrupt again and again

Shane,

The DisableLeasing registry key solved the "unrecognized database" problem for our customers, but it created one nearly as bad: a huge performance hit.

Our largest customer has about 9 Windows 10 workstations and a Windows 2012 server. Each client has an accde linked to a shared access DB (also an accde) on the server. They are running Access 2013 runtime on each workstation.

They were getting the "unrecognized database" error frequently, some days every five minutes or so until we applied the DisableLeasing workaround.

Performance was fine (more or less) until we applied the workaround, then it took a nosedive, and nothing we've done to date has improved it. It's so slow at times that we're probably about to lose them as a customer since we haven't been able to resolve it for them, and it's been several months.

Our other customers are experiencing the same performance hit even with fewer clients. They were also getting the unrecognized database error until we did the DisableLeasing, which slowed things down to nearly a crawl.

We need help, or we'll be out of business soon. Or at least out of the Access development business.

Marty Grant

Access Developer

Hey Wayne,

I certainly would love to be able to isolate and resolve the issue for those people that are encountering it.  Unfortunately, this problem doesn't occur on the systems we've tested with, and even for the customers who are hitting this, there isn't a clear pattern or set of steps that consistently lead to the error.  There is something in the combination of hardware and software environment, Windows and Access that are interacting in a way that is leading to the problems that people are seeing. 

I'm not going to go into details of our efforts so far, but will certainly let people know (through the Fixes and Workarounds page if I don't get back to here), when we having something better than the current workaround.

Shane Groff

Access Engineering

Marty,

I have Clients that have applied this fix with no performance hit.  However, I distribute the .ACCDB's because of issues with .ACCDE's.  Might I suggest you try at least one .ACCDB and see if the slowdown persists.  It's easy enough to protect the code with a password to the Modules so you don't *give away the farm* but you see if that's causing the slowdown.

Hi Shane

How about contacting one of the many posters who have sites where this problem is occurring - I am sure someone will allow you to remote login to a site to see it for yourself. You can then try to duplicate the conditions to see if you can reproduce the problem. Also you will be able to see the side effects of the "DisableLeasing registry key" fix.

Something has happened since one of the Windows10 updates 12-24 moths ago that is causing a lot of intermittent problems. Customers who had rock solid stability for 10-15 years now have lots of problems  - and some are passing on the stress they feel as they are the ones who upgraded to the solution that we and Microsoft was pushing them to adopt - ie Windows 10. 

Something is wrong with networking on Win10 and, because Access is a file-server database with lots of network traffic,  it is the canary in the mine shaft that is highlighting the problem.  However I am sure it is affecting other apps as well but the consequences are not as dire. 

Some effort should be put into finding a solution for this. Several MVPs are complaining - this is not just bad design or incompetence and Microsoft should treat it as a serious problem going forward.

I will now have to advise customers thinking about going to Windows10 to hang on to Windows 7 (if they can get a computer with Win7) - not a great recommendation when you think about security and other benefits of Windows 10. And if they do have to go to Win10!! -  cross my fingers and hope for the best because there is no programming solution I can implement to affect the problem.

Hello,

I don't want to sound rude, but your inability of replicating the problem seems to be just another excuse, such a company like Microsoft cannot repair obvious error in Windows 10 (and it IS in fact an error in implementation of SMB since version 1803) for more than half a year! There are EXACT conditions, just a simple research on the many forum posts that surfaced right after release of Windows 10 1803 would lead you to them.

Simple logic:

- it is sufficient to apply DisableLeasing to a server machine (contrary to the many times presented belief that it is necessary to apply the same to every client machine too) to workaround - hence problem lays in implementation of Leasing in Windows 10 1803. 
- every single corruption was caused by a Windows 10 1803 machine in a mixed environment of Win7 and Win10 client PCs; without the workaround, after buying new computers with Windows 10 1803, the frequency of the corruption raised - another lead, it is in fact Windows 10 1803. 

- multiple users reported that by reverting to Windows 10 1709 the corruption problem went away - another lead it is Windows 10 1803 (and possibly every newer version - we have yet to deploy release 1809 to our production environment, of course we are very afraid after the file deletion bug/zip bug/etc.)

For the problem to surface/replicate, you need 1) split database with BE on a server machine (possibly Windows 2012 Server) and 2) at least 2 or possibly more client computers with Win 10 1803 simultaneously READING from and WRITING to the same BE

Hi,

Not sure this followed with my experience which started about 6 months ago with the 1803 update.

My server PC with the BE is a Windows 8 PC.

3 other PC's linking to this PC had windows 10 installed.

There were 100% fine & have been for 10 years or so with previous versions & had been fine with 1709 for as long as that has been around.

As soon as these client PC's upgraded to 1803, each & everyone could cause the corruption on the BE.

Any of these Win 10 PC's could cause the corruption whilst every other PC including the Server on Windows 8 was NOT being used (I know because I was the only person around on numerous testing times) but the server PC did need to have the front end open (so technically I guess connected but no data being accessed)

As soon as I rolled the client PC's back to 1709 all perfect again & this is where it has stayed.

I did briefly try the disableLeasing but some other odd behaviour & within a few minutes just felt not worth persisting. This was a tiny test so not worth taking any negatives from this, could have been anything but as most referenced the server PC as windows 10 hard for me to compare.

Oddly and again really not tested but for months I had stopped one PC (Home!) from upgrading using the Metered Connection, not sure when but I guess last few weeks it has now upgraded to 1803 & seems OK. This PC is not used much & did use to need some relatively intensive use to trigger the corruption. Could still be vunerable but surprised it has not crashed it yet.

So my slight hope that it is in fact OK now in my situation.  1803. 17134.376

It did coincide with allowing Office to update, I think this is where 1803 slipped through during the switching off of unmetered (but was back on shortly after?) The odd thing again is I did not notice this upgrade & sure it was a very in your face "Feature" upgrade.

When I get a change I have a intensive test I can put it through & just see but it may not help others if the server is Windows 10 but a slim hope.

Hi bignose2, 

that is basically almost the same situation. The only difference is OS on the server (irrelevant from my perspective) and number of client computers (we have approx. 20 of them at our site, as of now 10x Win7 vs. 10x Win10). 

Our client computers do extensive reads/writes to the database, so corruption surfaces fairly quickly (the more PCs run 1803, the quicker/more often we get corruption). As you have said, your PC with Win10 1803 is not used much - that could still be a culprit to not triggering database corruption.

Your point with single PC corrupting database while server having FE open makes sense, although it is new to me. It is still a problem in SMB Leasing implementation of the client computers where concurrency takes place. My example of 2 or more clients doing extensive work on the shared database backend would arguably cause corruption faster.

Otherwise your situation is very similiar: PCs with Win10 1709 -> everything is ok. After upgrading to 1803 -> corruption. 

At one point, we will be testing Win 10 1809, but it is hard to do it right in the production environment while having other things to work on.

Shane, I find it almost unbelievable that you aren't able to reproduce this. This issue has been causing many people major issues for many months and and all you have to report is that you can't reproduce the issue? Hard to believe to be honest.

Thanks Gina. We haven't tried using the ACCDB to see if that helps.

Marty