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.

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.