Fix Windows 10 1803 Frontend - Backend corruption issues
We have some databases with a split front end (stored on local computer) and backend (stored on a server mapped via relative path) using Access 2016 (build 9126.2259). Since upgrading many computers to Windows 10 1803 the backend database constantly becomes corrupt. We have to disable the three caches referenced in the article linked below in order for the corruption to stop, but this makes file server operations much slower while also causing unnecessary network traffic. We never had this issue on Windows 10 1703.
What could be more clear: NO ONE at MS cares about users getting work done. I saw this years ago and moved on to MYSQL, Python, PHP and Linux.
I have one last client in MS and Access - thus the reason I'm here -
We need to make it clear to MS (if anyone there cares) that as we leave Access we leave all of MS -
Perhaps this will motivate them to act as if they care -
So, in discussions here and on other sites, and with others who have this problem, there does not seem to be a one size fits all solution. However, everyone, so is in agreement this problem is fairly clear.
But for the sake of clarity, was it Win 10 1803 or 1809 when it broke?
And it does not seem to be different in 32 bit or 64 bit.
The versions of Access effected are:
Also, 32 and/or 64 bit?
I know this is repition for some of you, but I'd like to get this as clear as possible for this reason:
I WOULD LIKE THE CONTRACT PROGRAMMER WORLD TO REALIZE THERE IS A LARGE OPPORTUNITY FOR A SOLUTION TO A HUGE PROBLEM. BY POSTING THIS HERE AND ON SEVERAL OTHER BLOGS THAT CONCERN THIS ISSUE, I HOPE TO INSPIRE EXPERT CONTRACTORS TO BRING AN EXPERT SOLUTION TO THIS MARKET. PERHAPS, IF IT IS GOOD ENJOUGH, MAYBE MICROSOFT WILL PURCHASE IT AND INCLUDE IT IN THEIR EVENTUAL SOLUTION.
Millions of MS Access databases have been effected by this and so have the programmers, contract or in-house, who have developed these time & labor saving applications.
I wish that this problem would be worked on with the highest priority, because this is extremely damaging to the reputation of Access.
by an access developer from Switzerland with over 100 access installations
Thomas Ruf commented
As a small developer for large companies with more than 200 database solutions developed in the past 20 years, it is absolutely incomprehensible to me how Microsoft has not been able to solve such serious problems over such a long time. I am very satisfied with Access, but unfortunately not at all with the way Microsoft solves problems.
Ali B. commented
Planned October 17, 2018 Are you guys for real?! You could have written a completely new software in this time period and still no fix.
Aleks R commented
I know I'm just venting, because Microsoft is "well aware of the issue", but holy cow, this is ridiculous. 15+ months and the problem is still happening? We have lost clients over the last year because of Microsoft's update fiascos. And the craziest part is that those fiascos keep happening. New update = new problem and new calls from clients who blame us. Even when we can get them to understand that it's Microsoft, not us, it doesn't matter, because that doesn't solve the problem. I'm so very tired of this crap.
NO ONE at MS gives a damn about users getting work done. This has been obvious for decades now - this CF being just one small example. I'm stuck in this junk now- but be advised MS, I never NEVER use MS products for any new work. MS is an attack on user productivity - but thank god we see MS becoming ever less vital to computing year by year as we all run screaming. Someday I hope to see them gone.
Kent Gorrell commented
This has just started to be an issue with one of my clients. One of those who had the 3340 error 2 weeks ago.
Seriously... is there any effort being made to address this?
Hans (Netherlands) commented
@Access Team: Can you please give some insight into the underlying problem and the status of the resolution you are working on. It has now been over a year, and although we have been able to mitigate the problem somewhat, this is still a very very serious problem. If the problem persists my superiors (company directors) will choose to move away from MS Access and all other Microsoft products due to the unreliability and Microsofts inability to resolve problems within an acceptable timeframe.
The main symptom of the problem is: Error 3343 Unrecognized database format.
But I am guessing that the following two errors are probably also due to the same underlying problem:
Error 3035 System resource exceeded.
Error 3040 Disk I/O error during read.
The recent Error 3340: Query <query name> is corrupt, gives my superiors more ammunition for ditching all Microsoft products. Fortunately, we were able to avoid a major disaster by disabling updates for Office, but (to my superiors) it seems Micosoft is losing control or just doesn’t care. Please help me prove my superiors wrong and fix these problems.
Heinrich Seeger commented
We urgently need help for our company from Microsoft. If not, we have to change our software systems.
Alan Cossey commented
It looks like the development team aren't in much of a hurry with this (or have sorted it and not told us). This has been waiting for a whole year now.
Does Office 2019 or Windows 10 1809 fix any of this?
is this fixed in 1809?
This has been affecting the organization I work for since last summer. Can we get a more recent update? https://answers.microsoft.com/en-us/msoffice/forum/msoffice_access-mso_winother-msoversion_other/access-database-is-getting-corrupt-again-and-again/d3fcc0a2-7d35-4a09-9269-c5d93ad0031d?messageId=c9ddd419-da56-42dd-a7ca-f93d29cf2c7f&page=14
Alan Cossey commented
How are you getting on 4 months into this, please?
Frank Rotolo commented
Pushing Win10 & Office updates without thouroughly testing is one more reason why my users have not upgraded past Windows 7 and Office 2010 Professional. I have a fiduciary responsibility to ensure that my users have a stable platform to conduct their business uninterrupted.
Peter Rühm commented
One of my clients had the same problem. IT refused to do the registry Chargers.
Converting the .accdb backend to .mdb made it possible to work with the frontend again. Luckily, I had installed some lines of code to manage the backend connection. But this solution is not satisfying: many other files are connected to the backend and can not be changed that easy...