Access Database is getting corrupt again and again

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.

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 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.

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.

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