I think at this point in time, after more than 3 years, one has to seriously question continuing to use Access back-ends at all! Maybe even question using Access at all considering the support we are seeing from Microsoft.
The Problem
Recently, the past few weeks, we have been seeing numerous reports of:
- databases getting repeatedly corrupted
- databases reporting “Unrecognized Format” or “Microsoft Access has detected that this database is in an inconsistent state, and will attempt to recover the database …“
and typically these are longstanding databases, that suddenly demonstrate such problems.
We Finally Have an Official Workaround
(2018-06-20)
Microsoft has finally published some info through their ‘Fixes or workarounds for recent issues in Access’, you can use the following link:
Access reports that databases are in an ‘inconsistent state’
They seem to be promoting the DisableLeasing registry hack (which was put forth by the community a couple days earlier – see below) as the solution and provide the steps to implement it (everything is explained in their link provided above).
Update 2019-08-14
That said, after a discussion with the Dev Team (2019-08-13) it would appear that the wording in the above article is misleading (they should be updating it shortly):
disable the leasing on the file server where the database is stored and the client machine where Microsoft Access is running
In fact, you should only need to apply the Registry Hack to the server housing the back-end file. You do NOT need to apply the registry hack to each user’s PC.
So basically, go onto the Server, open a Command Prompt and run the 3 lines provided in Microsoft’s article (above) and everything should fall back into place.
Also, some people report that this change has had a negative impact on their overall network performance, but this does not appear to be the case for everyone so you’ll need to test and see for yourself.
The Solution
Sadly, we now have reports that recent updates do not resolve this issue, so the workaround above remains the only Band-Aid solution for now.
Microsoft has been advised of the issue and they are investigating, but they have yet to identify the source of the issue. It does seem to coincide with Office 365 update 1803 & Windows 10 updates (KB4100403), but that may just be sheer coincidence. Time will tell.
Other Alternative Workarounds
The Workaround proposed by Microsoft (actually was found by a community user in one of the 1st discussion when the bug was first reported) is one possible solution, but does have it’s drawbacks: requires administrative priviledges on the PC/Server housing the back-end, appears to cause performance issues for some.
As such, I thought I’d post other solutions that have surfaced from community discussions on the subject and have be reported as resolving the issue.
Rollback the Bugged Update That Cause the Issue in the First Place
This one is obvious, if you rollback to Windows to 1709, before the flawed bug came out, well, you won’t have the issue at all.
Make a New Folder
As astonishing as this may sound, several users have now confirmed that simply creating a new folder (on the same drive) and moving their database to the new folder resolved the issue.
Change the Client’s FileCache
This is another registry hack, but there is a difference, this one doesn’t require any administrative privileges. The downside is that you have to apply it to each Windows 10 PC rather than the server.
The registry settings are:
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters] "FileInfoCacheLifetime"=dword:00000000 "FileNotFoundCacheLifetime"=dword:00000000 "DirectoryCacheLifetime"=dword:00000000
You save it to a bat file and simply execute it, et voila, no more problem. So far, no one has reported any performance issues either with this fix unlike the Official MS approved Band-Aid.
Switch To Using MDBs
Jean-David, in the comments below, suggests that switch from using accdb to mdb file format has resolved the corruption issue for him. After speaking with fellow Access MVPs, several also confirmed this as a permanent fix to the issue that they implemented and have been using for quite some time now without any issue.
There are now numerous posts in forums clearly indicating that switching the file format does not resolve this issue.
A Permanent Solution
Normally, we wait for a fix to come from Microsoft to put an issue to bed, but this problem is now heading on 3 years old and there are simply no signs of a proper fix coming any time soon. While the registry hack workaround works, it can impact network performance, some people don’t feel comfortable implementing it, … Well, I thought I’d bring up another permanent solution, migrating the back-end to SQL Server (or SQL Server Express which is free) or any other RDMS. By migrating, you can get around this entire issue and possibly gain on other fronts (no long have user limits, can be used over a WAN, …). Of course, you may need to tweak your front-end to work properly with SQL Server, so this isn’t something you just jump into. You need to upsize the BE and then test things thoroughly so you can detect issues and remedy them.
So if you’re tired of waiting on Microsoft to fix the problem they created and don’t seem to be in any hurry to resolve, consider simply upgrading your BE to SQL Server or another RDMS of your choosing.
Microsoft’s Response
Per the usual, there has been very little communication from Microsoft regarding this bug which is only adding to the issue since users are left feeling abandoned, yet again. Below are a few replies made by Shane Groff, from the Access Dev Team. The positive here is that at least he took the time to try and inform us.
Update 2020-07-09
Today, Microsoft posted on their Fixes and Workarounds page:
We have not been able to fully deploy the fix due to new issues that occur only when the fix is present. We are continuing to work on the problem.
So nothing has changed, we are still in a holding pattern.
Update 2019-11-27
As you can see below, more than a year and a half later, Microsoft still hasn’t managed to reproduce the problem accurately to properly remedy it.
The biggest problem with this issue is that we still don’t have a way to reproduce the problem in a controlled environment. Nobody has been able to give us a situation where it is “Do these steps”, then “Database is corrupted”.
We believe we understand the change in Windows that caused the increase in corrupted databases, and have been testing changes that we hope will alleviate the problem in production. Initially, that will be for O365 Monthly Channel users. It will not necessarily address all the issues, particularly in environments with users using different versions (if someone using Access 2016 corrupts the database, it may still be reported as corrupt when it is opened in Access365).
I am not suggesting this as a workaround, because I know it isn’t a trivial transformation, but if this is causing you significant issues, it is worth considering using Access for the front end, and storing data in SQL Server.
We will share more information when we have it, but I don’t want to make promises we can’t deliver on.
Update 2019-03-28
This was the latest post from Microsoft on the subject after 10 months of this bug
We continue to gather information from customers, and are testing a new approach.
This is not a simple issue, and in addition to the difficulty of isolating the problem, we also have to be careful not to introduce new issues.
The initial fix we tested for this problem introduced new issues that were worse than the original problem.
We are working on this, and I will post updates when I have more concrete information.
Shane Groff
Access Engineering
So nothing new to report. The wait continues!
Update 2018-11-15
So it’s been more than 5 months now and today there was a reply in a forum question from Microsoft that stated:
There isn’t anything new for this.
I don’t see immediately in this thread, but have you tried the suggested workaround to set the DisableLeasing registry key?
We still have not been able to reproduce the issue in a controlled setting, but are investigating some different possibilities.
Shane Groff
Access Engineering
As you can imagine, there have been a few post of disbelief at such a statement after 5 months of the problem existing. All I can say, is arm yourselves with patience and don’t could on Microsoft to resolve it any time soon. IMHO, your best bet is roll back your Windows installation to 1709. This whole situation illustrates why Windows 10 and Office 2016+/Office365 are still not ready for production use!
A Few Threads on the Subject
If you want to review some of the more recent threads reporting this type of issue, feel free to consult:
- Access Database is getting corrupt again and again
- Unrecognized Database Format
- Microsoft Access Database Corruption
Sadly most of the thread on this subject have been lost by the closure/removal of both the Microsoft MSDN and Answers forums.
Please be aware that in a multi-user environment where you have a shared Access front-end, EVERYONE trying to use the db MUST USE the same version of Access. You will see error messages like this if someone has the file open in, say Access 2013, and someone else tries to open it in Access 2010. Access cannot operate the same file with two different versions at the same time.
While that is true, one should NEVER be sharing a file between users. This is one of the most fundamental rules of deploying an Access database. Each user must have their own personal copy of the Front-End, preferably their own local copy.
We had the same problem.
I noted something additional that has not been referred to, which may help analysis of the problem. The .ldb file associated with my backend database was growing over time. I didn’t realise the significance at the time but at one point while watching the backend folder I saw the .ldb file instantly grow from 1K to 16K in size. Today the .ldb file grew from 1K originally to 15K later in the day, and actually had 229 entries at that time. I took a copy of this one. I think I got a better understanding of .ldb’s during this process. I believe they can grow bigger, but not get smaller. If a user exits the database, then their slot can be overwritten by a new user, but it does not actually get reclaimed. Now as the .ldb files grew in size, they contained a (small) number of genuine records, but also a large number of blank records. I checked with a hex editor, and there were many entire blocks of 64 bytes of chr(0). My conjecture is that maybe the handshaking required to link to an mdb is maybe failing, and having to be reattempted, but the failed attempt is incorrectly writing a stream of null bytes to the .ldb file. If there are a lot of failures, then eventually the .ldb file will become full, causing the database to crash. Maybe some connection attempts have to try several times, each one adding another block of 64 bytes. The discussion of the “leasing” registry entry meant nothing originally, but I now think it is probably part of the process of negotiating a connecting to the database. I Hope this helps.
I’ve passed along your comments to the powers that be. Hopefully it will help them figure this out.
Would you please clarify on option #2. do you disable all SMB versions 1,2,3,4? or enable all? or what?
Bob
From what I understand from Shane’s comments is that you need to enable them.
Just another thought on this. I could find no reference to this on UtterAccess.com, but did find some references on Access-Programmers.co.uk. I couldn’t see where the affected users were all from, but are US users reporting the issue, or is it restricted to non US users? Secondly, our backend database uses Access front ends, but also uses ODBC connections for non-Access applications. Clearly the problem isn’t affecting everyone, and I am trying to identify common factors between the users that are affected, and I wonder if the non-Access connections are involved somehow.
David,
I will chime in. with my setup, that has been running for years with very little issue.
US based, single office 13 users
2008 r2 server – hosting backend – accdb 2016 access
7 – Windows 7 Pro users running access Front end w/ linked tables to backend. access 2016
6 – Windows 10 build 1803 users running access Front end w/ linked tables to backend. access 2016
each workstation has it’s own local copy of front end.
Yes. Happening to US clients as well. I have quite a few that are getting constantly corrupted now. They had been happily rocking along for years until now.
I had two clients who had this problem early last week. Was very frustrating for both. But the problem disappeared for both clients on Friday. I wonder if Microsoft sent out a bug fix on Thursday….
I have a customer here in the UK with this problem, but it is complicated, perhaps, by it being used on a Windows 10 Home Edition peer-to-peer network.
This problem has been a SERIOUS nuisance for me too. It’s been going on so long I was getting this problem multiple times a day. I was literally causing serious amounts of stress at work. We are just a 2 person operation but I’m the only tech person and not being able to take orders because of this or if it crashes while helping a customer. I have been working with a developer because we have been using this mdb since around quite literally 2000. Converting to accdb from mdb does not help. I can only imagine the horror some of you may be facing with bigger clients. I need to be spending my time actually trying to run the business and pay the bills. Not get dragged down multiple times a day with this problem. This problem is like having a broken leg and getting having your crutches kicked out from under you several times daily.
We are also on w10 1803. I’m not certain if it’s a coincidence or not because I feel like we’ve been living with this problem for WAY too long.
At first when we were getting this problem I was literally restoring a backup from the previous night and manually re-entering all of the orders for the day based on our print outs. significant hassle, even for a small business like ours.
Eventually, and more recently I have just Access “recover” the database and this does seem to work without any data loss… except of course whatever record you were trying to update or create when it first happened.
But more recently it seems that the unrecognized format error is preceded by Disk I/O error during read. My developer recently did some changes to smb I think based on an article similar to this one. He said “We have ENABLED SMB2 AND SMB3 and we have DISABLED SMB1 which is the default of windows 10 but what I did was disabling OpLocks (opportunistic Locks) in ALL your computers not just the server.”
As far as different version of office, we are on O365 and I thought they auto update. We’re both using 2016 but as I inspect further they are not the same build. One was on semi-annnual channel and another was on monthly channel. The “server” is also on monthly channel.
I don’t feel as though it is network related. Network is all gigabit and no wifi
In our environment, we have discovered that Citrix XenApps tend to cause this error with multiple user applications. We instructed our remote users to open a VDI and use the installed version of Access to run the application rather than taking the lazy shortcut of a XenApp to go directly to it from the recents list. That allows us to go weeks without this problem, at least until someone forgets and I have to repair everything.
For my scenario and many days and hours investigating this issue, the Windows 7 workstations had no issues accessing and sharing the network mapped backend database. The backend database became corrupted as the Windows 10 (1803) workstations were introduced into the database and performed extensive query and table operations. Evidently SMB changes are the culprit in the 1803 update and the following fix (and workstation reboot) worked for me which was applied to all the Windows 10 (1803) workstations in this environment. 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
You may also review the “DisableLeasing” registry settings for Windows Server 2012 or above pertaining to the server side if the fix above does not resolve your problem.
Hi – your posts here in relation to Error 3343 Unrecognizeable Database has been very helpful in helping my clients understand the issues following the recent MS update that seems to have initiated the problem.
I have a couple of questions (please)
1. Do you know if the Registry workaround that MS suggested does the trick in solving the problem. A couple of my clients have expressed concern about making changes to the registry and so have not (yet) done this.
2. Do you have any further information from MS as to when they will provide a distributable fix?
Many thanks
Ted
1. From what I know this is the only proven workaround. So until MS releases an official fix, this is the only fix.
2. Nothing. I, like you, am waiting for an official fix but no new information has come out of Redmond on the subject.
Thank you David; very helpful.
Please keep us all posted of any news from Redmond.
I really don’t know what to say, we’re nearing the 2 month mark and nothing, not even any form of update on their own website on the matter. This is exactly why I dislike Office365 and these software as a service solutions and now to hear Windows is heading down the same road is even more alarming when you think of the QA issues we’ve been seeing in the past several years from Microsoft!
David Sandrovitch: re your Q above, one my users is running Office 365 with a FE on their Desktop and a BE on a Server running Windows server 2016 and windows 10. This user is having the issue 2 -3 times a DAY and needless to say are getting very frustrated with it.
As I have written above, their IT Support is reluctant to make any changes to the registry as per the MS Workaround but I am encouraging them to do so.
Interestingly at least 3 other clients of mine all reported the same Unrecognized issue after the MS update but fortunately, their instances of the issue have been far more limited. Two of these clients have a PC doubling as a Server but the other has a Server.
I hope MS come up with a fix soon.
I’ve been beating my head against the wall trying to figure out what was wrong with our system. Testing drives, network cards, etc.
At least I know it’s not just me.. Still super annoying. Happening MULTIPLE times per day at this point.
Have 5 sites affected so far, all recently upgraded to Access 365 and all have back end Access data file on Windows servers. But moving the back end file to a user’s computer and re-linking seems to work without error. I won’t even try a test unless Microsoft makes a statement about this.
You’re not going to get anything more than the link I already provided
Access reports that databases are in an ‘inconsistent state’
From my understanding, it is a windows issue (not an office update issue) and was eventually resolved at some point with one of the windows updates in July.
Thank you for this blog post. I was banging my head against a wall for a few weeks until I found this.
We’ve probably lost 20+ man days over this issue, the lack of official comment from MS is very disspointing.
In my case we had up to 55 users working for 15+ years on every version of Access from 97 and every version of Windows Client and Server. Recently we were using a mix of Windows 7 and 10 (1709) clients with Access 2016 backend hosted on Windows Server 2012. All was fine until 15 new Windows 10 (1803) PCs were added, then we started having this issue – sometimes several times a day.
Applying the registry fix to the specific server hosting the backend resolved the issue immediatly. I would like to reverse the change to the server but would like to see an official article from MS detailing what the exact cause of the issue was and the specific update that fixes it. We apply all updates vis WSUS and were still having the issue as recently as 3rd Aug.
“I would like to reverse the change to the server but would like to see an official article from MS detailing what the exact cause of the issue was and the specific update that fixes it.”
I think everyone would, sadly, we have seen no official news come out of Redmond in weeks. If ever there is any new official news, I will be sure to update my article, but Microsoft is horrible at communicating!
Thanks for your reply. That’s a pity, and a really poor way to treat developers and customers.
I have just run into the problem again with a database stored on a different server that didn’t have the registry work around applied.
The only access to this database is from my own PC which is fully patched (OS Build 17134.191) so it would appear that the the issue is not fixed by any July patch.
Have you had any issues since applying the work-a-round?
Slower, but fully functional
Thank you Daniel for the 8-August 2018 update. 2 days ago we made the Registry changes to my client’s server and after a couple of days, so far so good but it is early days yet as we have had 3 or 4 days clear running before.
Assuming the July Windows update does what MS says it does; do you think we should reverse the Registry changes or leave them in place? What is the DisableLeasing registry anyway?
Thank you again for leading on this issue.
I am not qualified to answer those questions, as I too am unaware of what DisableLeasing is/does. As such, I passed along your question directly to the Access Dev. Team and this was their response:
We’ve also had our system crashing regularly since the end of May. The fixes in the article actually helped – until the July Windows update. Once some of our computers updated, the problem returned with a vengeance. After updating every Windows 10 workstation to the July update for 1803, the problem went away – until today (8/10!). So pardon me if I’m a bit skeptical about the problem having been resolved…
I had this problem few months ago on update to 1803, coincided with other stuff no did not dream was windows update so spent a week personally (of time I can’t really spare) trying to fix, eventually rolled back but I have Win10 HOME on 2 PC’s so can’t (easily) prevent auto update. 1 pc just updated again just as I’m going away and really only one who can safely roll back if it tries again.
Does anyone know if the latest WIn10 update really has fixed this. Don’t have time to test properly now.
My options ??
If I did the reg fix on 1709 & if it auto updated to 1803, any idea if it would carry over
Prefer to stick with 1709 but if it does update while i’m not around. I found data corruption every 10 minutes or so, so completely unusable.
Update now to 1803& do reg fix anyway.
I’m amazed there is no real fury at MS for this especially as now a few months on.
Seems little or no info on the consequences of the reg fix, this seems bizarre that the MS advise page does not mention any possible side effects.
Are you sure the issue is resolved? We are still running into the same error and I have checked the PC is on build 1803.
No clue, communication is not Microsoft’s strong suit! From what I understood, the issue was never truly identified, but it looked like after a July Windows update that the issue went away for some, so then I think they just said it was solved. That said, according to the Access Workaround webpage the issue is still in Workaround status.
And this my friends is exactly why the cloud, Office365 sucks! We’re all at the mercy of Microsoft and more than 2 months in and we still don’t have any official solution and no updates since June 14th! and no ETA. That’s the level of respect Microsoft shows its clients.
Is it possible that a windows update would remove the disable leasing change to the registry? I think the workstation was missed but the network admin said he checked each workstation and suggested that windows update would change the windows registry. Any thoughts would be appreciated.
Anything is possible, especially with Microsoft! As for actually knowing if this is what is going on, I couldn’t say. I personally don’t know and haven’t heard from anyone about this. I think for the most part we are all in the dark, as is Microsoft it would appear. Per usual with Win10 and Office 365 we are simply at their mercy as we wait! I wish I had better news, or some actual information from the Dev Team, but they’ve haven’t been contributing or answering any questions in several weeks or even months now.
After applying the Win 10 Aug. 14 update to 1803 and any updates to Win Serv 2008 was stable for 2 days then “unrecognized database format” on server back end Access file returned to user front end after a good number of transactions that opened and closed the back end.
Yes, we been seeing posts regarding this (I updated my article yesterday to reflect this fact). The Disable Leasing registry fix remains the only workaround for the moment. Thank you for sharing this information.
Interestingly enough that was precisely our experience as well…it was stable for a few days then oh well
I am trying to research this for my company as we have also been battling customers database crashing. I am on our sales side, so do not have the technical background. I ran across this on another website:
https://github.com/MicrosoftDocs/windows-itpro-docs/issues/934
ITYIPMan commented on Jun 22
For my scenario and many days and hours investigating this issue, the Windows 7 workstations had no issues accessing and sharing the network mapped backend database. The backend database became corrupted as the Windows 10 (1803) workstations were introduced into the database and performed extensive query and table operations. Evidently SMB changes are the culprit in the 1803 update and the following fix (and workstation reboot) worked for me which was applied to all the Windows 10 (1803) workstations in this environment. 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
Any thoughts on this as a solution?
I can’t comment really. The only confirmed workaround has been the Leasing Registry key, beyond that I can’t say. You can always test and report back and I’ll be more than happy to post your findings for all to benefit from.
The work around has certainly helped as prior to applying these two things, it was almost a guaranteed event that would happen within a couple of minutes using our client. However the success has been somewhat short lived for me. As we have begun experiencing this problem again since around the end of August. It’s nowhere as severe as it was prior to these tips, but still a few times a day. I just decided to check reg edit and it seems somehow DisableLeasing was deleted. I’m not sure that happened. I suspect “Feature update to Windows 10, version 1803 (installed on 8/23/18)” is responsible for resetting the registry. Has anyone else checked to see if that’s the circumstance for this problem recurring since applying these hot fixes? I will report back in a couple of days to say whether or not this has indeed helped me again. If I have no further incidents today then I’m pretty sure it is a success. Should I disableleasing on only the server or clients too?
According to Shane Groff (Access Dev Team), and I quote, “you should do it on both client and server machines” (taken from Access Database is getting corrupt again and again)
And thank you for sharing all this information with everyone.
Does anyone know if the fix for this bug is included in the Oct. 1809 release?
As far as I know, no fix has been released and the issue is still in workaround status! Worse yet is there are reports that even after implementing the workaround that a recent update may reset the registry key, thus requiring it to be implement again!
Hi Daniel
Thanks for all the help and support you are offering everyone here. It is really good of you and has helped my confusion out heaps to hear I am not alone with this sudden issue appearing mid June. I’m glad I found your website.
I have applied the registry edit value for the disable leasing and we no longer receive the unrecognised database message or inconsistent state repair one either which is brilliant.
Since applying that workaround though we are now all experiencing really slow database speeds when working in it. Have you heard of this with anyone else at all and have I missed anything else I need to do or apply at the same time?
Any advice would be great but thanks so much again in the meantime.
Chris
This morning I got a call from a client with the “unrecognized database format” bug. This is a new customer with the Access split on two client Win 10 computers where one of the client computers, a fairly new laptop, has the back end database Access file in a separate folder along with the front end Access file in a separate folder. So this is a peer-to-peer set up, not the Windows server and Win 10 client set up that has been reported to date. Since I have been relocating (“bug” occurrence) back end files on the sites with Windows Server onto the primary user’s computer and re-linking other users to point to the new location I have not had any reports of the “bug” being reported. So this is a new occurrence for me, and a unexpected surprise.
I had a similar experience last week. The scheduling application I wrote for professional accounting firms has a tracking module which helped me identify the client machine that was causing the corruption. That user was able to log into Citrix and complete data input uneventfully. No other users on the network were having any difficulty although most run the application front-end from their personal computers. The client’s IT support group repaired Office and ran both hardware and software updates before re-installing the application. Once done the Access program which has been running successfully for several years was back to normal on the offending computer. I assume MS must have addressed the issue in a build after 1804 for the problem to “go away”. Have they released any further information to enlighten developers?
Nothing has changed. I even followed-up with the Dev. Team last week and never even got a response to my inquiry. This issue is still in workaround status, no official fix has been released.
Has anyone else experienced slow performance with MS Access since applying the DisableLeasing RegEdit?
Since applying it to all computers involved we haven’t had a single instance of ‘unrecognised database format’ or ‘inconsistent state’ errors which is great BUT we are all having really slow and sluggish performance now.
Closing forms with only a simple macro of close window on a button is taking a very long time and ghosts into (Not Responding) states too. The speed of the database and navigate forms is almost as big a problem for us as the original Compact & Repair frequency.
Interested to hear if anyone else has experienced this and/or has a solution to speed things back up while we wait for a fix
Thanks
Yes, several people have reported a performance hit. The issue being there isn’t much other alternative. Just be sure to create a persistent connection at the startup of your database, but that about all you can do to optimize performance. The real solution will have to come from Microsoft, and they certainly do not appear to be in any real hurry to do anything.
From my experience, it might be unnecessary to apply DisableLeasing fix on every machine.
First, we have tried this scenario – server configuration untouched, client computers with Win10 1803 with applied registry fix:
“FileInfoCacheLifetime”=dword:00000000
“FileNotFoundCacheLifetime”=dword:00000000
“DirectoryCacheLifetime”=dword:00000000
The result was zero corruptions, but terrible performance, almost unusable.
In fact, we have almost no performance issue with DisableLeasing applied only to server running W2016, while the client computers (approx. 20 PCs, a number of them running W10 Pro 1803) remain untouched. For a week, zero database corruptions. To be fair, some performance hit might still be present, but it is minor compared to the other registry fix.
Wow I thought I was the only one out there fighting this error until I found this blog. Here is my story and I hope it helps. I have done everything thinkable hardware wise except for what it says in this blog. Maybe by sharing my story it will help to solve this problem. We are running a Visual Basic application that accesses the Access database. Nobody accesses the database except for through the application. I had no Office 365 installed on the network until the beginning of October, therefore in my case I can’t tie it back to Office 365. The problem has been there since May. When the problem first came about I went through the entire network testing all cables end to end replacing any questionable cables. I removed unnecessary switches and replacing a 10/100 switch with gigabit switch. I even replace the main switch with a new gigabit switch and made sure all workstations and server were on the same switch. I verified that every desktop was set to gigabit and tested moving a large file to make sure they were all working optimally. Sorry to tell you this but after all this it did not make any difference but I now knew that it was not a network issue. My case was so bad that if I had a single user running the application it worked fine, as soon as another user got into the database it would crash it. I remove all antivirus and it got better now running for a day or two without crashing. At this point I’m starting to make headway. The server is 4 years old, RAID 5 and also a solid state drive in it. I moved the database to the solid state drive and it would run for a week or two with no problem but as the database grew the problem seemed to get worse. Here’s the crazy move… As the server was 4 years old and I had recently sold the business owner a new Dell Optiplex Desktop 16GB of memory and a solid state drive on it I moved the database to it. We are talking 25 users using a Windows 10 desktop for a server. The database ran for almost 2 month without crashing! It seems to be s speed/latency issue with the server. I have now order and installed an $15,000 Dell server all solid state hard drives 64GB of ram my guys are doing the data migration tomorrow night 10/10/18 and clean up Thursday 10/11/18. I’ll let you know the next time it crashes I’m hoping never. Keeping my fingers crossed I hope that Microsoft gets the update out and the problem does not occur again.
I hope this help someone out there.
From the entry above, the server did not solve the problem, it made it worse. Not only did we end of with the Database unrecognized format but then it started blowing up on table errors. Seemed like the database kept getting disconnected.
If anyone out there knows the solution to this problem please post it.
This is the only, well tested, workaround for this issue caused by recent updates. This is the first time I have heard reports of this workaround causing more corruption. I have however had several reports that it causes slowdown. That said, the error itself has been around for a long time and could relate to other issues (not just the flawed recent update). So you could be instead dealing with corruptions, network issues, …
I think you misunderstood what Calvin Sawkins meant by “the server did not solve the problem”, he was reffering to his replacement of the server machine itself instead of applying the registry fix for server (DisableLeasing).
After reading his posts I came to conclusion that he never applied any registry fixes and also takes wrong steps to ammend the issue (by buying new server). Also the idea of speed/latency issue as the culprit seems wrong to me. The problem looks more like bad caching/locking in SMB implementation of W10 1803 (hence the registry fix for client computers that all deal with cache timeouts). By disabling leasing on the server it seems to work around the problem – the client computers can no longer use that feature for a file (database) shared from the server.
The best fix which has solved all our access issues for multiple customers in the UK is to upscale the back-end to SQL, job done.
We have had some luck with disabling oplock and SMB1 on all clients and just disabling oplock on the server. This did make things better but we are constantly holding our breath for the next corruption/crash. Most of this is from inherited systems we look after as we always advise away from Access where possible to something that isn’t file level, can be backed up while in use and doesn’t completely corrupt as easy.
The way forward has to be to move away from Access as this seems to happen far too often being even more susceptible to change with monthly feature updates for both Windows and Office, Microsoft clearly will not provide specific fixes for any of this and only point to workarounds. This makes it even more obvious that Access has no real future for multi user systems going forward.
I’m starting to agree that sadly, because of the instability of Office/Access in the past 2-3 years (since Office 2016) that the only way to guarantee functionality is to move away. I’ve actually starting migrating my clients away from Microsoft altogether. It is so sad. Some have been using Access dbs for more than a decade, but after continuously getting updates that break databases, the downtime costs more than replacing the entire system (having 10+ employees not able to do their work and clients are on the phone…).
Microsoft just doesn’t seem to get it! This very bug is a prime example 4+ months and still nothing.
Although there are many reasons to pour scorn on recent versions of Office, I should point out that I have a customer still running a couple of my Access applications on Access 2003 and one of those has been suffering from exactly the same backend corruption problem since Windows 10 upgraded itself to 1803 so this is very much an operating system ‘feature’ rather than an Access problem. Thanks for the thread though because like many contributors here, I was considering desperate measures before I read it.
Yes, that makes perfect sense as the issue relates to a flawed Windows not Office. So it can impact any version of Office upon which Windows has received said update.
Planned obsolescence? Maybe. As someone who is slightly technical but by no means a developer, Access has been really great for me because I’m still able to some basic queries projects on my own without having to hire out. But in my mind, Access almost seems largely unchanged over the past 18 years. New skin, new ribbon/tool bars, but ultimately, at least for the stuff I used virtually nothing different. We only just switched from mdb to accdb this year because we thought it may have been a contributing factor in this issue. I would love to see it overhauled or moved into visual studio. All access objects become text files, that you can keep track of in a git repository. The building tools etc. already exist in VS, I mean it looks to me that basically visual basic was pulled from VS in order to create access IDE. But perhaps it’s too late. Pipe dreams though I’m sure.
Hi,
I can’t seem to post on MS community anymore, .. corruption time and time again.. “Opps something went wrong, try again” does not seem to be locked. Anyone else with that problem?
I was going to post the following..
Hi,
I have so far had success with ITYIPMan’s suggestion as below & not yet tried DisableLeasing.
I would love to know the difference & which is the better option if both work.
Much to my annoyance both PC’s auto updated to 1803 (from 1709) despite my Win 10 Pro PC as deferred? and my Home PC on Metered so I thought I would try again (especially as too late to roll one back!)
My server (very average) PC however is Windows 8 but both networked FE’s are Windows 10.
Did the reg fix as below & no corruption yet. I have a test loop that I run & it does X number of rapid form updates that I know are written to the BE.
Before the reg fix it would crash, usually after just a few loops, however sometimes 50 or so,
which is very frustrating for testing. have done 300 loops about 5 times, whilst the Server PC FE is doing the same (not on the same record though).
Tested on my second PC now & also been using as normal & 99% sure OK & would have corrupted by now.
Does not seem to be any performance hit at all but my use if fairly slow & easy & only 3 PC’s a the same time & that is very minimal.
ITYIPMan
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters]
“FileInfoCacheLifetime”=dword:00000000
“FileNotFoundCacheLifetime”=dword:00000000
“DirectoryCacheLifetime”=dword:00000000
What is annoying is I have another PC for backup & testing, I rolled back to 1709 ages ago. Would like to put 1803 on to test but it does not offer the update now, if I use the upgrade assistant it wants to go to 1809 & I really don’t want to open that can of worms yet although it would be interesting to know if perhaps this has fixed any of the Networking & corruption issues.
To be honest not searched for anyones experience of 1809 & these access corruption problems, I guess as they had quickly pulled this update no one really wanted to risk this with threats of lost files!!
As being rolled out again I wonder if worth a go. In fact might try on my test PC shortly.
I had a client that had the back end Access file on an MS server and the “bug” showed up Nov. 8, 2018.
So I moved the back end Access file to the primary user’s Windows 10 build 1803 PC and reconfigured for a peer-to-peer configuration. Then on Nov. 28, 2018 the “bug” came up again. This is my second peer-to-peer configuration to come up with the “bug”. The first time a client had a peer-to-peer get the “bug” was back on Oct. 4, 2018 and I applied the disable leasing registry entry and the “bug” has not recurred since. So I applied the disable leasing registry entry to this second instance and will advise status about a month from now.
As far as I can remember, ever since disabling leasing, my mapped network drives do not automatically connect on boot/login anymore. A small price to pay in order to not suffer this unrecognized nonsense. However, it would still be nice to have them automatically reconnect. Is anyone else experiencing this?
That’s why I added the Word of Caution box, the last time I applied the fix all mapped drives stopped working. If you don’t get prompted for the credentials then I recommend trying to recreate them.
I’m having similar problems
Two of my clients have had definitely this issue, but applying the work-around to the server only does seem to have improved things, at least to the extent that they no longer complain. They are expecting a permanent fix from MS asap, as their server support providers insist that this can be a short term work-around only. Another two clients have reported occasional “unrecognised format” messages, but can live with having to repair the data files in the short term. It is very likely that others are doing the same, or have found the work-around themselves; I have not yet asked everyone.
It’s been 6 months and still nothing from Microsoft, so your clients better get real good at waiting!
As for the solution, when I implemented, I applied it to all the PCs, as well as the server and haven’t had the error message since, so I recommend you do the same. Hopefully it will remedy the issue for you as well.
Even if they are willing to hack the Registry on all PCs, how do you ensure that the hack remains in place on all PCs, including mobile laptops, indefinitely? If the issue does resurface, I might suggest moving the back-end to a Synology NAS. Apparently a lot of small businesses are ditching Windows Server in favour of these in any case. See 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?auth=1&page=11
The issue here is that a NAS is not s Server. It all depends on your needs. For simply file storage a NAS becomes a valid options, but a server can do far, far more, Domain, AD, DHCP, … It all comes down to your needs. You also have to be very careful with which NAS you purchase as they are not all created equal and some make/models cannot manage running a multi-user database.
Never the less, yes, a NAS (not running Windows 10) can be a great options and eliminates the entire unrecognized database issue.
Thank you for sharing.
I hate to disappoint, but we have a small office with the Access backend stored on a NAS, and the problem was as rampant as anywhere else. The only solution that worked for us was the one posted above by ITYIPMan. The recommendations from Microsoft did nothing.
As it’s been six months now dealing with this, I’ve had ample opportunity to keep an eye on this, and we have only had problems when a new computer without the adjusted registry settings connected to the database. In our office all the workstations are running either Access Runtime 2013 or Office 365.
Sharing your experience is never disappointing! 🙂
I’m surprised the Reg fix did not work for you as I’ve used it at numerous clients offices now and have yet to encounter a case where it failed. You did apply it to all the computers involved and the server.
There is also the fact that this error can also be related to normal corruption, unrelated to the bug itself, which make it that much hard to truly determine the root cause of the error!
I think the author of that link was suggesting ADDING a Synology NAS, not replacing the server. This is a much easier permanent fix than upgrading to SQL Server, for example. (However, I know an ex-SBS support expert who switched all her clients to Synology NAS when SBS was discontinued. So she must have found decent alternatives to all common SBS functions. Certainly not feasible for all users though, and requires expert help and careful planning.)
Thought i’d throw my 2 cents in.
Running Windows 10 and have installed KB4480116 (17763.253) and now I am getting the error:
“[Microsoft]ODBC Microsoft Access Driver] Unrecognized database format ‘C:\Program Files(x86)\xx\xxx.mdb'”
This did not happen with 17763.195.
I have tried all known workarounds to no prevail. As the DB is local to each machine there is no server involvement.
Hoping Microsoft release a fix soon!!
Levi
This works for me (for now).
https://allthings.how/fix-microsoft-access-unknown-database-format-error-after-windows-update/
Yes, for Access ’97 exclusively. This error is caused by a new issue caused by an update released earlier this week.
Levi, you can find the solution at
Windows January 2019 Updates breaks access to Access DBs
https://borncity.com/win/2019/01/11/windows-january-2019-updates-breaks-access-to-access-dbs/
He did an excellent job writing this up. We have already tested the dll replacement workaround and it fixed the issue on both Windows 10 and 7.
Has anyone determined if this is fixed in 1809? We have a mix of 1803 and 1809 clients.
According to official channel (ie the MS website) it remains unresolved.
We are suddenly (starting last week) experiencing this issue.
Our back-end file is stored on a server running Server 2008 R2. Is there any workaround for this server version?
I believe the Microsoft workaround applies to all versions. I’d start there.
It’s strange – I made a fresh install of Win 10 1083 and experience all these severe problems described here. My partner has Win 10 pro 1803 – she probably updated from a previous build, but she doesn’t experience any problems with the same Access app… What could be the cause? Different updates?…
had 2 access databases working just fine Fe local copy, BE on a dedicated server access 2013 and office 365 server crashed and a new server along with new s/ware (but not on workstations) was installed
Now getting all the problems mentioned above regisistry settings changed last night will keep you posted on the result ms should be ashamed,this is a major fup and it needs fixing
I noticed today that the Microsoft support article about this issue was changed and it now provides details of a windows update to fix the problem. It describes the problem differently and it appears to have had wider impact and just affected shared Access databases more than most. Does this mean it’s fixed?
https://support.microsoft.com/en-gb/help/2957623/cannot-access-shared-files-or-folders-on-a-drive-in-windows-server-201
The article you reference is 3-4 years old. Funny how it is the exact same workaround though.
The official article on the subject https://support.office.com/en-us/article/access-reports-that-databases-are-in-an-inconsistent-state-%ef%bb%bf-7ec975da-f7a9-4414-a306-d3a7c422dc1d?ui=en-US&rs=en-US&ad=US remains unchanged, still workaround status.
We are an ISV and have the same problem with our Access application sharing the backend accdb database on a Windows file server. I have found the DisableLeasing registry entry on the server fixes the problem so far. However, I do get resistance when asking a customer to do this as it affects the entire server and all file sharing and may have performance ramifications. I think I ran across a way to turn off leasing mode on the server for a particular share instead of the entire server. I am wondering if anyone else has tried this and had any success. If it works, I can suggest to my clients to place our backend database file in its own folder and share that folder. Then set the leasing mode to none on that share only. The command you can issue in powershell (run as admin to start powershell) is “set-smbshare -LeasingMode None” where is the share name. Has anyone tried this instead of the registry entry to disable leasing on the entire server?
We have the same problem, after using the same access database backend on the server(server 2016) and front end on upto 8 client computers (windows 10 office 2013) at a time this worked fine with all versions of windows and office since 2002 with never a problem until last summer then the unrecognised format started to happen regularly. I have tried every solution i could find on the net but still haven’t found a permanant fix.
sometimes it will go several weeks with no problems then a computer will come up with the error, and will have to be repaired before any computer can access the data. Once this happens it will happen every few minutes that same day then may not even happen at all the next day, it is very random.
It may happen with only one computer accessing the data and also tried blocking each computer in turn from accessing the data incase it is any of the computers causing the problem.
All computers including the server have the lastest updates and builds.
in dire need of inspiration.
Firstly, have you applied the registry workaround, it has worked for me in all cases I have implemented it.
Secondly, unrecognized database error can also be related to normal corruption. So if you are running on a Wireless network, WAN, unstable/saturated LAN, have an improperly designed database, an unsplit database … are just a few examples of possible ‘normal’ corruption sources.
Daniel, have you tried “set-smbshare sharename -LeasingMode None” where sharename is whatever you shared the folder as. I am thinking this might be preferable to doing the disable leasing change on the entire server. We could share the folder with the backend database, give it a name, and just set the leasing mode to none on only that share. The question is will this work and has anyone tried it? It would minimize any detrimental performance impact on the server in general.
No clue. I simply implemented the workaround from MS and haven’t truly devoted any time trying to figure this issue out. I thought MS would have properly resolved the issue by now. I never thought we’d still be dealing with this 8+ months on!
Mark, That sounds very promising. I suggest you post on 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?auth=1 where Shane, a senior MS engineer is chipping in.
I did reply on the Microsoft forum as you suggested so we will see what happens with that. Here are the details I suggested and am trying in case anyone else wants to try it.
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. I would be interested in any feedback on this approach:
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,
Great reply by the way!
As always, thank you for sharing.
Well,the work around for the time being has worked – but the performance hit has been large as far as speed accessing the data is concerned
Daniel – Thanks for sticking with this bug topic and work-arounds. This lack of accountability from MS is just another reason way I’ve moved away from Access developing. In the past, my 2000, 2003, 2010 applications were rock solid. Any bugs found were developer bugs and not OS bugs. Today, it is not uncommon for OS bugs to bring applications to their proverbial knees. Not correcting these bugs with the next update is unacceptable in the business world.
You summarized my thoughts entirely!
I have no words left for the ‘New Microsoft’. Home users are nothing more than guinea pigs and free QA testers. Their support is non-existent as proven by this latest bug. Sadly, I doubt this will change moving forward. MS is raking in the money with the cloud, so everything else is irrelevant.
I think you were a brilliant man to move on!
“We continue to gather information from customers, and are testing a new approach.
This is not a simple issue, and in addition to the difficulty of isolating the problem, we also have to be careful not to introduce new issues.
The initial fix we tested for this problem introduced new issues that were worse than the original problem.
We are working on this, and I will post updates when I have more concrete information.
Shane Groff
Access Engineering”
I see that MS finally updated their bug report on April 4th: “We have been able to gather additional data about the causes of this issue, which are due to usage patterns in the Access Database Engine with networked files that did not cause issues with previous versions of Windows, but no longer work properly. We are testing a fix for this problem now, and will give further updates when we can confirm that this resolves the issue.”
Yes, an update of sorts, but absolutely nothing has changed as of yet.
WOW, finally something from Microsoft…
https://support.office.com/en-us/article/access-reports-that-databases-are-in-an-inconsistent-state-%EF%BB%BF-7ec975da-f7a9-4414-a306-d3a7c422dc1d?ui=en-US&rs=en-US&ad=US
Important: April 4 update: We have been able to gather additional data about the causes of this issue, which are due to usage patterns in the Access Database Engine with networked files that did not cause issues with previous versions of Windows, but no longer work properly. We are testing a fix for this problem now, and will give further updates when we can confirm that this resolves the issue.
Periodically when I reboot, my mapped network drives aren’t disconnected. And I wonder if I windows update was responsible for that. And while I haven’t experienced the problem during these occasions, I am periodically running the script to disable leasing just to make sure some windows update isn’t undoing it.
For those of you that have moved the backend to Synolgy NAS or FreeNAS. How long have you been running the solution, how many concurrent users. Even though I only have 3 users, the performance hit on some things is annoying. Especially when you have a back to back call and you’re still waiting for an operation to finish while you’ve already answered the next call.
The last time I tried moving the back end off of windows was quite literally over 10 years ago. We tried putting it on Fedora 6 and at that time, it was not possible for multiple users to access the backend at the same time because of the way the linux permissions locked it to just a single client. And my linux server knowled is almost non existent, so I haven’t thought of this since.