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.
Does anyone know if this problem persists if the back-end data is moved to SQL? We were experiencing multiple errors every day until Daniel pointed me to this thread and we moved all Access databases to Win 7 machines. Since then – no errors. But I know that the day will come when I need a new machine and have to go to Win 10. With the recent Microsoft comment on the issue, maybe a fix will happen before then. Or maybe not. I’m also looking at using a Virtual Win 7 machine – has anyone tried that? Thanks for any comments!
Hi Michelle, Migrating the back end to SQL Server is the ideal solution to this issue, and also resolves many other issues with Access back ends in a mission critical production environment. However, the conversion is usually a big project, and someone may need to learn a lot about SQL Server, so in many cases it is simply not feasible. Good luck!
There are also certain design changes that need to take place as you don’t design a db front-end the same way if you are using an Access back-end vs. an SQL Server back-end. So while the change can be beneficial, it is not something to dive into lightly and it is not necessarily a fix all either.
In Microsoft’s perfect world we should all have ported Access to SQL Server. In 2003 I committed to developing an Access application specifically dedicated to my companies specific needs. Keep in mind we fully intended up sizing to SQL at a later date. Sixteen years later I run my entire company on the application. Over 10, 000 sales orders & invoices, production scheduling, project tracking, 50K inventory sku line items, full accounting, the entire gamut of business software. I fully intended to up size. The spoiler was it ran every day, flawlessly, never an unrecognized date base error for 15yrs until 1803! We followed all the rules of proper database design , updates, and maintenance. Speed and response time for 8-10 users, running the back end on MS Small business server was effortless, fast and dependable. But not any more come build 1807. Build 1809 has improved stability but we are still encountering occasional unrecognized db errors. All workstations are running 1809, and Server Essentials 2012 currently. So bottom line MS unfortunately no longer has the commitment to Access we once enjoyed. Which is unfortunate. Thank you MS for 15 very successful Access years! Unfortunately the successful run has ended.
Perhaps you could consult with some of your previous dedicated developers and learn about commitment and dependability. While you get paid to develop software users like us only get paid if it runs. And yes I own the company.
I wish I could argue your point, but I can’t. I’ve been told things in the past few years which pretty much collaborate your conclusions. It is not normal, or acceptable in the least, that a year later we are still dealing with the ‘bug’ and that it has become the new Microsoft norm that the end-user figure things out.
Access has always been the black sheep of the Microsoft Office family, we have seen this time and time again. I suppose this is no different.
I always come back to the same thought though: If Satya actually used Access and was facing this issue and dealing with clients facing this issue if it would have taken a year (or more) to resolve! But of course, it’s more important to develop new Office 365 icons rather than invest in fixing a year old bug on Access. It’s all in the priorities!
I was wondering if you have heard anything if the new windows update 1903 will have any help with the access problems?
No, absolutely nothing has been communicated since there April 4th update on their website. It’s be over a year now, so I truly wouldn’t hold my breath. Implement the workaround and move on.
Daniel, has the workaround caused any issues with your clients after the credentials issue? Could you elaborate on “all you need is to reenter the credentials” because it’s not clear to me where? Is that for each workstation and each mapping?
And finally you may be aware of this from Microsoft but in the article
https://support.microsoft.com/en-us/help/2696547/detect-enable-disable-smbv1-smbv2-smbv3-in-windows-and-windows-server
they specifically say in a separate warning box that doing this is NOT to be left on permanently. So we have MS saying don’t do it and MS saying do it. I don’t expect you have an answer for that of course, but it’s why I’m asking for your experience since it appears you’ve done it and had it in place for months at some clients.
Hi Bill,
After the update was implemented and I tried to access one of the mapped drives, I received a popup for the credentials in which I simply entered them and everything worked fine afterwards. Worse case scenario, you delete the mapped drives and then recreate them.
Yes, we shouldn’t be implementing such a workaround in a permanent manner, but Microsoft has left all of us with no choice as more than a year later we still don’t have a fix. Obviously, if one day they do release an actual fix, we should undo the change. My clients haven’t reported any side effects with the workaround in place.
But of course that instruction from MS totally justifies IT staff refusing to implement the workaround. It could also justify the company migrating away from Microsoft altogether!
Indeed.
You’re not the first to state this and I have personally help a couple of my client migrate away from Microsoft completely. It also interesting to see recent article showing pretty big performance gains by using Linux vs. Windows/Office. More fuel on the fire.
It also doesn’t help that we have seen no fix in over a year now. That’s the level of supposed support Microsoft’s end-users get. So the next time people go on and on about “software going out of support”, I say to them “What support”!
Microsoft’s last post dates back to April 4th in which they stated a fix was being tested (hinting at imminent), here we are 3 more months later and nothing! It’s sad to see how Access is just not important to Microsoft.
And the waiting game continues.
Hello,
We have a Windows Server 2008 R2 server with a Access 2003 BE, and Windows 10 1809 (17763.592) clients with the FE (access 2007 and 2003). The problem of continous corruption of database arised us from last week.
We apply the disableLeasing only in the server, but corruption appear as soon as a client connect to the BE. Then we apply the smbfix on all Windows 10 clients.
No corruption so far, but the slowliness is impacting more than expected on the clients. Some processes were impossible to maintain with the fix applied.
Hi Daniel,
I am suggesting an alternative to the above listed workarounds.
If environment let users to do so, copy the front end locally, do the work and push back to the previous location.
May or may not possible/applyable to all users/environments.
Thanks.
The front-end should already be local in any multi-user Access database. Do you mean the back-end? Yes, move the back-end locally, relink the tables in the front-end, perform the work, and then copy the back-end back to the server. This kind of defeats the whole multi-user aspect of the database, is time consuming and is prone to mistakes (accidentally overwriting the server with the wrong version of the back-end, 2 users working locally and crushing each other’s work, …). In well controlled environments this could be an option.
That all said, the real solution remain for Microsoft to actually resolve the matter (more than a year now we’ve all been waiting!).
I think that more and more, Microsoft is pushing users towards alternate RDMS for their back-ends. So consider migrating your back-end to MySQL, SQL Server (SQL Server Express which is free), PostgreSQL, …
Thanks for the advice.
At least MS are still working on it…
“July 1 update: We have been testing a fix for this issue but have discovered problems as currently written. We are working to resolve these issues and will then engage in further testing.
Due to the complexity of this issue and the need to ensure that we aren’t introducing any additional problems, the release process for this issue will span more time than a typical fix. Please continue to monitor this page for further updates.”
They’ve been working on it for over a year and testing an update since April. So, no, I’m not impressed or even hopeful at this point. It doesn’t take a year to fix an issue, sorry, but it just doesn’t. It doesn’t take 4 months to validate a fix.
If they wanted to address it, it would have been done long ago. It just shows that this is not deemed an important issue. It may eventually be fixed, but certainly isn’t getting the resources it should have otherwise it would have been solved within a few weeks, month at the most.
Hello,
We have a Windows Server 2008 R2 server with a Access 2003 Back End, and six Windows 10 1809 x64 (17763.592 version ) clients with the Front End (access 2007 and 2003) affected with this problem.
We disabled the disableLeasing fix in the server due to performance problems. We maintain the SMBFix in the windows 10 Clients combined with the replacement of the msrd3x40.dll library on the clients. We replace the 4.00.9801.16 version dated 12/06/2019, by the 4.0.9801.5 version dated 20/09/2018.
After these changes, and until now, there has been no database corruption issues. We have verified a performance dicrease in the Access application, but in any case lower to the one produced by the DisableLeasing fix.
Thank you for sharing and I’ve passed along this information to the Access Dev Team in the hopes it may helps them figure out a proper fix to this issue.
Daniel, thanks for keeping this up to date. I have run into this issue with a database I developed for a local charity. Got the workaround implemented and, knock on wood, so far so good. But highly concerning and disturbing that MS have essentially left developers high and dry here. I cannot imagine the stress that full time access development companies must be dealing with as a consequence. Such a shame that this amazing software is being doomed to death by neglect like this.
Hello,
After some time, we restore version 16 of the msrd3x40.dll library and maintained the smbfix.
To date we have not suffered any episode of database corruption. And the overall performance is acceptable.
Hello,
Could you please detail the steps you did til now? Because we are facing constantly database corruption and already tried to rollback Windows 10 to 1709 version, tried to restore msrd3x40.dll to an old version and still have problems. What did you mean with “maintained smbfix”? I can’t find what we are missing to, at least, implement a workaround until Microsoft solve the problem.
Why don’t you just apply the registry fix per 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?
I tried to do it on workstations but I got no luck, that’s why I rollback to verion 1709. Beside the databases are on my File Server, I didn’t apply the registry fix on it to avoid other issues for most of my users. Is there a recipe or a step by step that I can follow on my workstations? For example:
1 – apply registry fix on workstations
2 – check if msrd3x40.dll version is …
I’m seriously thinking about return to Windows 7 Pro…
Thanks in advance.
When I have implemented the registry hack, I applied it to all the PCs and the server housing the back-end file. Never had any issues afterwards with the database.
If you omit just one PC or server you risk still encountering the issue.
Hello, Daniel, thank you for you patience.
We didn’t change anything in our server (Windows 2008 R2) and we had only Win 7 Pro in our environment, and the problems apparently started after we upgraded some PCs to Windows 10 1809.
The workaround that worked for you was just the registry fix or you changed something else, like msrd3x40.ddl’s version? Do you know if I must apply this fix in any version of Windows Server’s version?
Thanks,
Just the registry hack, nothing else. I didn’t want to mess around with too many things and just stuck with exactly what Microsoft was suggesting. Since it worked, I just left it at that. This also makes reverting the change easier since there is only one thing to revert.
I applied it to every computer that ran the front-end and the server hosting the back-end, per Microsoft’s instructions:
The entire issue is a Windows 10 issue. If you only had Windows 7, then you would NOT have this problem. So the minute you throw one Windows 10 PC into the equation problems arise! It is a Windows 10 update that actually caused all these headaches.
No clue as to why we have not seen a proper solution from Microsoft considering that the bug is well over a year old. No clue if we ever will.
Exaclty, it’s incredible that Microsoft couldn’t fix the problem yet. Tomorrow I’m gonna move the files to another server that I can apply the registry fix, as I’ve already applied to PCs and I post here the results. If anything changes, I will have to revert PCs back to Windows 7 Pro.
Heads up, I asked Microsoft to improve their documentation on the issue and in our discussion on the subject I was informed that the Registry Fix only needs to be applied to the back-end server and does NOT need to be applied to each individual PC.
Unfortunately I had to rollback to Windows 7 a dozen machine of a specific department, but I’ll try to implement that recommendation on a different department.
I see that MS have now updated their workaround instructions; to confirm, only the file server needs to be patched:
https://support.office.com/en-us/article/access-reports-that-databases-are-in-an-inconsistent-state-%ef%bb%bf-7ec975da-f7a9-4414-a306-d3a7c422dc1d
I converted an Access database originally created in Access 2007 to 64 bit in Access 365 64-bit by adding the required PtrSafe keyword to various Declare statements along with altering some Long variable data types to LongPtr data types etc. I also put a conditional compilation statement in the VB code as follows:
#if VBA7 then
#If WIN64 then
#Else
#End If
#Else
#End if
The idea being to catch all flavours of VB and Windows.
I then found that I could not open the database in Access 2007. Got the “database is in an unrecognised format error”.
Having got the error, I got a backup copy of the database, did the same PtrSafe and LongPtr etc changes and put the following conditional compile into VB
#if VBA7 then
#Else
#End if
In other words, got rid of the reference to WIN64. This worked. The database could be opened in Access 2007. I went to the first database and removed the WIN64 conditional compilation but I still got the error.
I then created a new database in Access 365 64-bit and imported all the elements (tables, queries, forms, reports and modules) from the backup database and put the non-WIN64 conditional compiles into it but still got the error.
I then created a new database in Access 2007, opened it in Access 365 64-bit and imported all the elements from the “unrecognised” database into the new database (which already included the non-WIN64 conditional compiles). The new database then opened successfully in Access 2007. Compiling the visual basic modules in Access 2007 revealed a couple of LongPtr data types that it didn’t like which were solved with the conditional compilation #If VBA7 then #Else #End if for those specific occurrences, and the database then ran like nothing had ever happened.
I can open it in Access 365 64-bit and compile it and Compact it and it still runs in Access 2007. The key seems to be starting with an Access 2007 database, either an existing one or a new one and then not putting WIN64 conditional compiles into it. Creating a new database in Access 365 64-bit or putting WIN64 conditional compiles into an Access 2007 database seems to create a “different” type of database.
Thanks for all this information! At least I know I’m not mad and alone on this 🙂
I’ve been using splitted Access databases for +15 years and never had such problems, it is a reliable product and a core component in the company I work for. The SQL BE approach is something to consider but involves a lot of testing to be sure that everything is working fine.
I’m living with this bug since about one or two weeks ago, first blamed a slow network, a faulty switch, antivirus, etc. And then found this thread and the MS official “fix” for it.
I will try to apply the registry change and see what happens, this was shortly after moving the BE to a Win 10 1809 machine. Seems like if this don’t work I’ll have to switch back to the older slow server (its about 150 times slower) but this corrupt database issue will be gone (hopefully), so its about slow and secure vs fast and broken.
In the meantime I’ve discovered that every single time the DB get broken no real damage has been introduced to the data itself, its a matter of kicking off all logged users (shutting down all the front-ends), deleting the .LDB and loading the BE into Access, then click on Accept to the “unrecognized format” information dialog, then wait for the Repair and then click Accept again and exit Access.
It is a total PITA but it works, sadly you have to been there to apply it. I haven’t found a way to “repair” a MS Access database without user intervention, you have to click in the Accept dialogs.
Is ther any CMD line we can use to repair the database? I know there is the /compact swith but it doesnt work because it can’t compact something that is “broken”.
I know how to catch the error and therefore launch something that kick off users (a timer that check for some value that is activated when error 3343 shows up).
It is a brute force approach, but this is way out of hands now. All I miss is a way to automatically repair the database without having to click on Accept, something like an autodrive repair.
Any ideas about this?
PS: Probably a small VB/C# .NET program can be used to load the back end, repair, compact and keep going
Thanks,
So far so good! To all the people having this problem, I can confirm the fix works 100% and it only needs to be applied to the hosting machine (not the clients)
Since the registry fix was applied (requires admin rights) to the machine with the back-end, because its a splitted database, all the problems are gone 🙂
I can breath again and continue to make effective solutions with Access as usual.
The machine runs Windows 10 v1809 64bit, Access 2016 32 bit (16.0.4849.1000) using .MDB files. Spanish version (both Access and Windows).
Thanks Daniel and all the people in this thread!
An alternative to your Permanent Solution is to migrate the users to Terminal Server / RDS. This can involved moving the entire user desktop over to TS or to just make Access based database available as an App.
This solution is useful when a complex MS Access based database needs a major performance upgrade. This can be achieved ensuring that the data is on the same server and is only accessed through a direct local path and not through a network share path.
By the same token, the corruption issue disappears because the data is no longer accessed via SMB.
The plus here is that the application code does not need to be changed. The down side is that a TS has to be configured with additional costs involved.
We have used this approach many times when a major increase in performance is required (often increasing by an order of magnitude). A bonus is that it also solves this problem.
Thank you for sharing and I fully agree with your statement. Another great possible solution.
Has anyone having this problem also seen their vba code coming uncompiled? A split production mdb that has run fine for a long time started having the problems addressed in this thread, but also the vba code will come uncompiled, making execution slow dramatically. Both issues happen, it seems, when the dB has about six concurrent users, which I know is a soft limit. Another dB that never gets that loaded has had no problem. It’s not unusual, lately, for me to get a call that it’s running slow during peak need, I recompile it and do c&r, the an hour or so later, I get the roar addressed in this thread. I’m wondering if I have one problem or two. Thanks for any input.
This does not ring any bells with me, and the symptoms do not seem to match the issue discussed here, so my guess is you have a different problem. But you can prove that by trying the work-around of course. There are very many split mdb with VBA applications running fine with many more than 6 concurrent users, so it sounds to me that something specific in the design of that DB is hitting a different Access limitation.
It have noticed that after a few months DisableLeasing entry has been disappeared from the registry, supposedly the work of Windows Update.
I have observed this on a couple of user sites, has anyone had the same experience?
To aid with monitoring I have created a script to test for the presence of the setting:
str = readfromRegistry("HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\DisableLeasing", "Registry Fix missing") Select Case str Case "Registry Fix missing" wscript.echo "Registry Fix missing" Case "0" wscript.echo "DisableLeasing set to 0 - needs to be set to 1" Case "1" wscript.echo "DisableLeasing set to 1 - all OK!" End Select function readFromRegistry (strRegistryKey, strDefault ) Dim WSHShell, value On Error Resume Next Set WSHShell = CreateObject("WScript.Shell") value = WSHShell.RegRead( strRegistryKey ) if err.number 0 then readFromRegistry= strDefault else readFromRegistry=value end if set WSHShell = nothing end functionAs of yesterday we have the same problem. In our company we are using the database for years now, with +/-40 people.
Database is split and the users have a local front end. The back-end keeps crashing after a repair. It works a couple of hours and the problem reoccurs.
The only thing that I can think of is that not everybody is working with the same Windows version.
Some have Windows 10, others still have Windows 7. Could that have something to do with it?
That is the only thing that has changed recently.
Yes, the issue is yet another bug in Windows 10 (not Access). So the minute you have a single Windows 10 computer, this becomes an issue and you need to apply the registry hack to the back-end server.
Found this thread because a client of mine seems to be having the same issue as is reported here, but the difference seems to be that they are using the 32-bit version of Access with .accdb files. I’ve only seen mention of 64-bit Access and .mdb files here so far. I was wondering if anyone has seen this issue resolved after upgrading all Win10 PCs to the 1903 build?
I just finished upgrading all Win10 PCs at a client’s location to 1903, and have not yet implemented the DisableLeasing registry fix, so I may have a better idea if it is fixed by 1903 in a couple days. The issue is intermittent and can go a full day without appearing, then have multiple issues throughout the following day.
Robert
Bitness is not a factor in this case, at least not to my knowledge. And no, 1903 does nothing to resolve this issue! The only workaround, turned permanent solution since it has been well over a year now, is the Disable Leasing registry hack.
Yea, I found out today that upgrading to 1903 doesn’t help. I’m about to implement the reg hack for this client. It’s a bit strange how this only started happening ~ two weeks ago, and I know they’ve had 1803 and 1809 on their PCs for some time.
Anyway, glad I found this thread and will be keeping an eye on it.
Thanks,
Robert
Hi Daniel
First of all very comprehensive and informative page here.
My back end database is running on the latest MS virtual server and host. Would I need to apply the fix to the host, virtual server or both do you think?
Thanks in advance
I sent the question along to Microsoft and they replied “you’d want to apply the fix to the virtual server, since that is the layer that is hosting Access”.
Please report back your experience as it may help others.
I had the same error on our access db
I found a solution that works for our db:
in the clock and region-change date, region-Administrative-Change system locale…
remove the “Beta: Use unicode UTF-8 for worldwide language support”
I’ve read through most of these comments, and may have found an answer to a question I have, but I’m going to confirm. Am I to understand that if your “server” is a Windows 10 computer instead of Windows Server 2016 or 2019 you can apply the reg fix to it? I’ve been hesitant to implement that fix on a couple of my customers sites where the “server” is a Windows 10 box.
Darrell Bowman
The issue arises from (a single) Windows 10 on the network accessing the database. In such a case, it is necessary to apply the Registry Hack to the back-end computer/server.
Can I move the backend .accdb to a linux network share or something like a Synology NAS. The last time we tried putting the backend on Linux was probably back in 2007. If I remember correctly, at that time it seems that once the backend client was accessed by one user, it became locked and other users couldn’t connect. Although we haven’t had any corruption problems since this hotfix, the network performance hit on certain queries or reports is just really nuts. For example a really basic query to look up an address by order id will often take tens to hundreds of Mbps throughput for several seconds. And I could literally drag and drop the whole backend database from server to client several times in the same time span.
I just encountered this problem for a client who converted their workstations to Windows 10. The Access front ends are on the workstations and the back end is on a Windows Server 2012 Standard. I upgraded from MDB to ACCDB and the error keeps appearing. Is the only solution still to apply the Disable Leasing Registry Hack to both the workstations and server?
Daniel, thanks for all of your hard work on this. One of the things that I noticed in the reply from the Access Dev Team is that they can’t reliably generate the error. My company makes software that is powered by Access. As such, a small number of my clients are effected by this issue. While these clients consistently produce the issue, they can’t do so reliably. My hope is to find a specific sequence of events that will generate this issue so that I can provide this to the Access Dev Team.
I am trying to figure out what pieces need to be in place to generate this issue, but so far I haven’t been able to reproduce the issue within my office. It could be that I just haven’t tried hard enough or whether my current environment simply won’t generate the issue.
The backend database is stored on a Windows 2012 R2 Essentials domain server in my office. I am connecting to it from two Windows 10 machines. I have confirmed that the two recommended workarounds have not been applied to either the server or the Windows 10 computers. Do you (or anyone else), happen to know if there are any specific settings that seem to specifically relate to this issue. For example, is there a way to specifically enable leasing (although I gather that is the default) or would disabling/enabling SMB 1, 2 or 3 help to generate the issue. Also, if the issue isn’t known to happen on Windows 2012 R2 Essentials servers, that would also be useful to know.
I appreciate any help or advice that you can offer.
Would putting the front end and backend on a Citrix Server solve the backend corruption problem?
The Citrix Server has Win 10 (1803) and Office 2016 only (Not with Office 365).
No.
I have a MS Access, multi-user, frontend-backend, application that has been used every working day for 18+ years without any problems whatsoever. Now it is going down every day. IT dept. will not try the Server Registry fix. Question: Would putting the backend on a shared NAS device instead of a Windows Server solve the problem?
Not sure. Since the issue arises from Windows 10, I’d assume that a NAS won’t solve the issue, then again, I’ve never tested.
The real issue is the IT Dept. The Registry Fix is the official Microsoft approved workaround, anything else is asking for problems. Heck, NAS devices with Access are unpredictable, some work, others bomb. They could solve the issue in 2 minutes, instead you’re going to start experimenting with all sorts of others things?!
Daniel,
I finally persuaded the IT Department to apply the Registry Fix last night. No problems with the database today. Happy New Year!!!
If the NAS device is not Windows then surely it would resolve the issue. I expect that another perhaps easier option is to put the back end on a separate Windows PC and disable leasing on that.
Another suggestion from Mark Mauger is to disable leasing on a share created specifically for the database:
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=26
David, I thought I was going mad for the past month, after our company upgraded to Windows 10 / Office 365 (Version 2016) / Access 365 (Version 2016), and our Access 2013 started corrupting daily. Someone sent me your link today. It seems the only workable solution is this DisableLeasing registry hack workaround, which may have performance issues. Am I bottom lining this correctly or am I overlooking anything ? I probably have to sell & work with my IT Support to get this to happen, which is no small task.
Nope, you’ve understood the situation properly!
As for your IT Dept. Send them to the official Microsoft page on the subject, that should get them onboard. You can also point out that this has been the recommended solution for over 18+ months now, so it is unlikely that an official fix is coming any time soon, so waiting is pointless.
Daniel, thank you for your blog! The way that I persuaded the IT Department to do the Registry fix was to show them your postings about disabling leasing on the server.
I can see why you are a Microsoft MVP.
Hi folks. I’ve been running dozens of split Access databases for 20 years on network shares and the performance has been rock solid. Some 30 users might be using the databases at any one time, and I have continued to develop databases as they have given my organisation such functionality and integration of data. We moved from Windows 7 to Windows 10, Office 2013 to Office 2016 in December 2019, and now all the databases are suffering with this problem which my testing in October 2019 did not expose. I am very glad to have found this blog – thanks very much for putting this together. All I can do is keep fixing when I can, and petition for the Server registry fix, and think about SQL server. I’d really like to know how much I would need to do to existing front ends to convert them,
Hi Matt, Have you tried the Alternative Workarounds listed at the top of this article? Did moving the back end to another folder not work for you?
Regarding SQL Server, it is impossible to estimate the work involved without an intimate knowledge of your application, and even then there tend to be surprising side effects with any complex system. But in some cases it is very straight forward. I can help on a paid basis if you wish.
Matt, I am in the same boat as you, with the same experience. When I finally convinced the Server IT Dept. to apply the registry fix the problem was solved overnight. I have not noticed any increased slowness in any of my applications since the fix was applied. Performance is excellent.
We are already using a sql server back end with an Access front end. We don’t have this issue on our production copies of the front end, but the development front end that I’m programming in is giving me the “unrecognized format” or “inconsistent state” errors frequently. Seems to start by bloating the db file size every time I save my vba changes and then eventually gives me that “unrecognized format” / “insconsistent state” message. Sometimes I’m not able to recover the front end after that, so I’ve taken to making copies of my development front end frequently. My understanding is that the issue as described above is isolated to split access databases, but I’m having it when doing development work even though we are using sql server back end. Am I alone in this? Should I still attempt the disable leasing workaround?
For the FileCache hack, what pathway should be specified? Any other individual changes that need to be made to work on my teams laptops
We have this problem since the transition from 1709 to 1809 in a very large organization and here is some information:
– This problem also appears on NAS with SBM3 share;
– We will test the deactivation of the client filecache on a test bench in the coming days; ([HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ LanmanWorkstation \ Parameters])
– We are validating with the premium support from Microsoft the solutions that are emerging;
I believe that Acces highlights a problem which would come in fact from Windows 10. According to your comments, we would speak since 1803. With 1709 we did not have this problem.
Thanks! I finally got some information for my problem. I will explore the several workarounds in the article.
Does anybody know if the following Windows update fixes the issue as it mentions a fix for SMB ?
https://support.microsoft.com/en-gb/help/4551762/windows-10-update-kb4551762
We have tried both workarounds in this article, and although they work, we are facing quite noticeable performance issues when the workaround is applied.
Kind regards,
Matt
There has been no development on this issue yet, so no fixes. The same workarounds remain the only options. The waiting game continues.
Thanks Daniel, unbelievable isn’t it, considering Windows 10 is supposed to be the operating system in support.
We have a number of users who fall into this problem, but oddly some of them have not encountered it at all. Perhaps there is some other criteria that makes it occur or more likely to occur.
Just a shame the workarounds have an impact on performance for us.
I faced the same issue (corruption / inconsistent state) for several weeks after migrating to Windows 10 (1709). Implementing the workaround from Microsoft was not an option where I work. I then found 2 workarounds, the first one really working in my case:
First workaround: Replacing all ACCDB back-end files with MDB back-end files. This completely solved the problem. Currently, I am using ACCDB front-end files with MDB back-end files. I have password sets on the back-end but do not enable file encryption. No corruption since then! (To do this: simply create a new MDB file and transfer your back-end objects to this new file.)
Second workaround: In all VBA modules, using DoCmd.OpenQuery (with a query object) instead of DoCmd.RunSQL (with a SQL string). This is not very practical to implement, but it did reduce the occurrence of corruption by about 80%.
I only use the first workaround (MDB back-end files) .
In trying to use the first workaround… what does it mean to use ACCDB front end and MDB back end? I’m having the same issue, my database itself reads 116TH BEB ADLOG 2020.accdb. It keeps creating backups when I try to open it but the backups also wont open. How to I do your change to MDB?
I was really happy when I saw the clent-level hack because, according to the article, “this one doesn’t require any administrative privileges.” However, I am finding that I can’t implement this hack because, in fact, I do need administrative privileges and I don’t have them. Nor can I get my IS team to implement the hack for me.
Am I missing something here? Is there a way to implement the client-level hack when you are not able to manually enter new keys? I also tried to do it with a vbs routine, but no luck…
Hello,
as for the others, once upon a time everthing worked smoothly: we happily used Windows 2008 Server to host the Access DB files and our users used our program through a pool of RDP W2K8 servers; since when we moved to W2K19, everything broke down: we are getting tons of “disk or network erros” when the DB is accessed using SMB.
We stumbled upon your post while desperately trying to solve our problem; unfortunately, disabling the leasing in the file server did not work: we restarted the “server” service, not the server itself, and the event viewer is unhappil reporting the warning related to the “DisabledLeasing” – hence I assume that the change is in effect; prior to that we disabled the leasing on a per-share basis, again without any effect. We also tried disabling the cache on the W2K19 acting as clients, again without any effect (yes, we did reboot them).
Are we the only one unable to solve the issue applying the suggested registry hack?
Thanks!!
Hi Giorgio,
It is not clear from your post that this is the same issue. If you are sure it is the issues reported at https://support.microsoft.com/en-us/office/access-reports-that-databases-are-in-an-inconsistent-state-7ec975da-f7a9-4414-a306-d3a7c422dc1d?ui=en-us&rs=en-us&ad=us then I suggest you post to the thread at 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=50 since this is being monitored by Microsoft and numerous users experiencing this issue.
Regards, David
Has anyone had the experience of having the Disabled Leasing registry fix stop working after a Windows Server patch. We implemented the registry fix about a year ago and it immediately solved the backend corruption problem. There was a Window Server patch done recently and started getting the backend corruption problem again. The IT Department tells me that Disabled Leasing is still set on the server.
I just got an update from the IT Department. Even though a patch was scheduled, they are now telling me that they the patch was not applied.
So, for some reason, on Monday morning, the backends starting getting corrupted again as they did before the Disable Leasing registry fix was applied one year ago. Has anyone had the experience of the Disable Leasing fix to suddenly quit working?
I have seen other people reporting similar behavior in which they applied the registry fix and suddenly it was gone (presumably an update reset the setting) and they needed to reapply it.
I had the IT department rerun the Disable Leasing registry change, reboot, and check the Registry. They told me that DisableLeasing is set to 1. We are still getting the continual backend corruption. I wonder why the Disable Leasing fix worked before, but it is not working now.
I am getting desperate. Do you think it is worth a shot to try the Client Registry fix on the user’s PCs?
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters]
“FileInfoCacheLifetime”=dword:00000000
“FileNotFoundCacheLifetime”=dword:00000000
“DirectoryCacheLifetime”=dword:00000000
I have 120+ users, but it would be worth it if it fixes the problem.
It can’t hurt to try.
That said, beyond this bug, there is true database corruption which will give the same error message. Could your db be corrupted? What about trying to import everything into a new fresh blank database shell to see if that helps at all, compile to ensure the VBA is good.
There are three separate multi-user databases involved. They all went down the same morning due to backend corruption. I brought them back up and they went down again, etc., etc. I have several single user databases and databases that are only used by one person at a time. They did not go down and are still up and running.
So it looks like the infamous Windows 1803 update problem.
We are still struggling with this, continuing to get the unrecognised format messages if more than one user works on a split database. It will be the end of our organisational use of Access and a sad way to finish what had been great for the best part of 20 years.
Matt, I think the Access community at large all feel your pain. We are all in the same boat and I completely understand and fully agree with you statement. I, myself, have migrated my biggest clients away from Access because of this mess, and all the other bugs since Microsoft switched to their new approach to development (using users as their testing guinea pigs) circa Office 2016 and have moved them over to PHP/MySQL/Azure. Although a considerable amount of work to accomplish, it is simply night and day! Too me, Microsoft has been putting the nails in Access’ own coffin for several years now. When a problem such as this one goes unresolved for well over 2 years … well I think we can all understand the importance the issue and Access has been given by Microsoft’s Management.
It is very sad indeed. Where I used to promote Office to all my clients, promote Access and therefore the purchase of Office licenses, I now am advising people to avoid it at all cost.
On one of my databases I tried testing the Client Registry fix with only three concurrent users this morning and the backend got corrupted again. For the past year, the Server registry fix was working perfectly. I was hoping that since the fix on the server had quit working, the Client Registry fix would work, but it did not.
I wonder if Microsoft has issued a new update or security patch that keeps both the Server and the Client registry fixes from working.
Hi Von, I have not had any reports from clients who have the server patch applied, nor are there any reports on the usually very active MS thread for this issue (link posted again on December 8th, above.)
So it appears that either this is something special to your setup, or there is some other reason for your back end corruption as Daniel suggested.
I hope you can get it resolved soon.
Seasons Greetings from David Nye
Hi David,
I am experiencing it on all three of my multi-user databases. They work in single user mode but when minute other users get in the backends get corrupted. We had this happened a year ago and it was fixed by applying the Disable Leasing registry fix on the file server. Then suddenly on Dec. 7th 2020 it started happening again. The files are still on the same file server and I had IT check the Disable Leasing setting. They told me it is still disabled. I tried the Client Registry fix, but that did not fix it either. Yesterday, I did as Daniel suggested and created brand new front ends and backend files and imported the objects into them, compiled, etc. A new folder was created on the server in which the backend was placed. This morning shortly after multiple users entered the database the backend became corrupted as before.
I wonder is it would be useful to pay Microsoft to look at our network to try to determine the reason “Disable Leasing” on the file server quit working as a solution. One recent change we had on the Client PCs is that they were updated to Windows 10 version 1909. I don’t know if that has anything to do with it.
Hi all,
same problem on our company. Many Access FE running with their BE on standard fileserver.
Most of the time when this “…database is in an inconsistent state…” happens, several employees where on that DB simultaneously, and I assume at least one via VPN (homeOffice). May this also has an impact?
I now tried to apply this Registry fix on one user’s PC (mine 🙂
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters]
“FileInfoCacheLifetime”=dword:00000000
“FileNotFoundCacheLifetime”=dword:00000000
“DirectoryCacheLifetime”=dword:00000000
It’s been said above that this one doesn’t require any administrative privileges. But on my side it does.
I get the message about insufficient privileges.
Any hint?
Thanks a lot
Martin
Is this a split database where each user has their own local copy of the front-end? If not, that should be your primary concern at this point as you should never share a common copy of any Access database.
Also note, this error can also be due to ‘normal’ corruption. Thus, have you tried creating a new blank database and importing everything to see if that helps at all?
Thank you for your prompt response!
We use several different front-end Access-DB ‘applications’, shared on a file server, which are linked to one single back-end DB. (I know, this is not the proper way to do it, but this is how it work(ed)s for over 20 years now.
At least the front-ends are commercial without support from the developers anymore. But the back-end with its tables I could refresh by creating a new blank database and importing all. I’ll give that a try.
I wonder if upgrading the file server software to the latest version, Windows Server 2019, would make any difference.
It won’t solve this issue.
That is what I have gathered from the other posts.
The reason that I brought it up is because I have been discussing this issue with Microsoft Support and that is what they recommended as a solution.
I was hoping that Microsoft made an update to Windows Server 2019 that finally fixed this problem (I know that is too good to be true).
I checked with the Access Dev Team directly and was informed that they were unaware of any changes made in Server 2019 that would resolve this issue.
Von, you said “One recent change we had on the Client PCs is that they were updated to Windows 10 version 1909. I don’t know if that has anything to do with it.”
My guess is that this was indeed the trigger. As you also said, the puzzle is why the server patch stopped working for you when it still seems to work elsewhere.
Would it be feasible to test with the backend on a different machine? Even temporarily on a workstation or NAS for example?
David, I had the IT Dept. check when the Win 10 version 1909 updates occurred and, for most of the PCs, it was a couple months before we started having the problem, so I am guessing it was not Win 10 ver. 1909 that caused the problem.
Recently, I moved one of the databases into Citrix with the database files stored on a NAS device. Within Citrix the users log onto one of four Windows 2016 servers that have Access 2016 installed. The users are effectively, bypassing Windows 10. So far, after one week, there have been no backend corruptions. I don’t know whether it is because they are bypassing Windows 10 or because the .accdb files are located on a NAS device, but it is working. I plan on moving some other of my other databases into Citrix.
Hi Von, That is great news and potentially useful information. Hopefully Daniel can pass it on to MS, or we can re-post it on the MS monitored thread? I am told that Citrix is quite expensive, so I guess your organisation was already using it for something else? From my limited understanding, I find it hard to see how a non Windows NAS could suffer the same issue, but we have at least one report that moving the backend to a NAS did not resolve it; maybe something else was causing the same error in that case. Either way, if you get the chance to test it please let us know the result.
Hi David,
The applications in Citrix are working well. What a relief! I suspect that the reason they are working is because the users are bypassing Windows 10 completely. When they log onto Citrix they are actually on one of four Windows 2016 servers with Office 2016 installed. They are not really in Windows 10 at all. Citrix insulates them from the Windows 10 installation on the Client.
Then again, maybe it is because of the NAS. I don’t know, but it is working.
I tried using Microsoft Support to try to determine the reason, but they seem to be completely clueless. They are in sales mode. I think they are just pushing Azure so they can collect their monthly toll.
It was identified that the entire issue was caused by Window10, by using Citrix, the way you are, there is no longer any Windows10 in the equation, problem solved.
Doing a yearly check-in on this issue. Does anyone in the access team work there anymore?
Also checking every once in a while…
The support page on the microsoft site is not updated in more than a year.
https://support.microsoft.com/en-us/office/access-reports-that-databases-are-in-an-inconsistent-state-7ec975da-f7a9-4414-a306-d3a7c422dc1d?ui=en-us&rs=en-us&ad=us
Any updates on this? We have been plagued with this for years. I’m relieved to find this thread and that we are not the only ones.
No, no updates whatsoever. MS hasn’t updated their page on the subject in ages and I haven’t heard anything either. It’s pretty clear after so many years that this simply is not a priority to them and are focusing their resources on other things.
I can’t believe this bug is still in place, it’s caused us no end of problems with leaving our Access DBs in an inconsistent state and making them operate much slower. We use the registry fix solution, and although it works, it has a massive impact on performance when working with many forms. Oddly, some of our clients we have never needed to initiate the registry fix on, so no idea why that is, as all of our machines run the same version of Windows 10.
The funny thing is, on the 8th July last year, I opened a new service request with Microsoft in our company Office 365 platform asking if there was any news on a resolution to this issue as its now been such a long time. I never received a response, but then the page on Microsoft’s website (as Daniel has linked to above) was updated the next day (July 9th 2020)
I wonder whether Microsoft are just fobbing us all off, but I really hope they do fix this problem.
Windows 11 is being released on 5th October, so who knows, maybe the problem doesn’t exist in the new operating system. I’m not expecting anything though as Windows 11 is really just the next update of Windows 10 with a different name.
Matt
I’ve put the question to the Dev Team and am still waiting for a reply. I’ll let you know when I hear back on the subject, if I hear back.
That said, based on what I know of Windows 11, I highly doubt the issue will be resolved, so I don’t think upgrading will be the solution for those affected by this bug.
I finally heard back and was informed that they simply don’t know at this point in time.
The answer caught me off guard as I would have expected that with a new OS coming out some serious testing would have, long ago, been underway, especially with such a longstanding bug. I know originally, they had a great deal of trouble even replicating the issue and don’t know if that continues to be a factor in its resolution.
Also, between summer vacations, COVID, yet another change in leadership within the Dev Team, … I don’t know what to make of the entire situation. At the end of the day, we, the users, will need to test it out and figure things out for ourselves and, once again, not count on Microsoft for much of anything. Fingers cross we see a miracle on October 5th!
Thanks Daniel.
The fact they don’t know simply translates to “no” for me unfortunately. I will be very surprised if the issue is fixed in Windows 11.
I would imagine not being able to replicate the bug is still the issue they are having, as it is a very intermittent bug (at least I found anyway)
Matt
Three days ago a client encountered this problem for the first time. Fortunately, applying the registry edit workaround in the client session made the problem go away.
This system’s backend MDB is on a Windows Server 2019, and the frontend MDB runs in a Windows 10 terminal server session on the same server. A mapped drive letter is used for the path. The system had been working without problem after having been moved to this server a month ago.
I’d recommend switching from using a Mapped drive path to either UNC or IP based paths.
Hi Daniel,
Do you know if using UNC paths gets around the bug entirely?
I’ve not done any testing with this, but if it does work, I could quite easily make some adjustments for our application to use UNC instead of mapped drives.
The UNC recommendation is not related to this bug at all, it is a general Access best practice.