Front End Access DB constantly getting "inconsistent state" error when more than 1 user opens it

Question

Front end: 2013 Access stored on Windows 2012 files server.  Physical Server with 4 x NIC Team

Back end:  Windows 2012, SQL 2012 Standard.  Physical Server with 4 x NIC Team

Multiple users share front end Access DBs connect to back end SQL.  It's been working well for the past few years, but since early May, if 2 or more users opens the .accdb file, when 1 closes out, they get an error "A problem occurred with removal of personal information from this file. Some personal information may not have been removed".  This happens even if user didn't make any changes.  Once this happens, the next person tries to open the DB gets the database is inconsistent state, and Access locks up on user's computer.  Only way to fix is to get everyone out of the DB and repair.  

Have verified network traffic and hard disk utilization are fine, no hardware errors on either file or SQL server.  Only change made is Microsoft Office patches released around May 1st.  

Wondering if anyone experienced similar issues in the past and know of a fix.  Thanks in advance.

---

Roget Luo

Answer 1

Hi Roget,

It seems that the issue is related to Access database. To better fix the issue, I will move the thread to Access forum for more help.

Thanks for your understanding.

---

Best Regards,
Winnie Liang

---

Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact [e-mail].


Click here to learn more. Visit the dedicated forum to share, explore and talk to experts about Microsoft Teams.

Answer 2

Hello Roget Luo,

You could try to go to File->Options->Current Database to check if the "Remove personal information from file properties on save" option is checked. If it is checked, clear the checked.

Best Regards,

Terry

---

MSDN Community Support
Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact [e-mail].

Answer 3

I just want to make sure of your setup.  Does each user have their own copy if the front-end or are they sharing a common copy?  They need to each have their own dedicated copy (typically copied locally onto their PC).

---

Daniel Pineault, 2010-2017 Microsoft MVP
Professional Support: http://www.cardaconsultants.com
MS Access Tips and Code Samples: http://www.devhut.net

Answer 4

Thanks for the suggestion, Terry.  Tested it out on couple of the DBs but still same inconsistent issue.

---

Roget Luo

Answer 5

Daniel,

Users are sharing a common copy which we know is not a good way of doing this, but it worked just fine the past 2-3 years, even during times when we are 10+ users working in the same DB.  Something changed around beginning of May, and the setup no longer works.  Currently, we have only 2-3 users working in the same DB, most of time, users are just reviewing information, not making any changes to the data.

I'm wondering if Microsoft changed something in Access with the Office patches released in May.

---

Roget Luo

Answer 6

Try the way the Microsoft engineers designed it to work in the first place in a multi-user environment. Distribute a copy of the Front-end file to each user on their own machine linked to the Back-end file. But first, when everyone is logged off the application, make sure there are no .laccdb files in the directory where the Front-end or Back-end files reside. Sometimes these "lock" files do not get deleted automatically when the last user closes the file like they should. If you find an .laccdb file still in one of the directories, just delete it.

Answer 7

Hi, I'm experiencing the same issue that just began a few days ago, around 28 May 2018.

We have a split MSAccess DB--BE on a PC, with 3 FE on laptops all connected using MS file sharing (not a "real" network, per se). 

Everything has worked fine for several years, then suddenly, after a Windows update a week or so ago, we began to get the "inconsistent database" message on a daily basis. Our fix was to disconnect everyone, reboot all the systems, and do a Compact & Repair on the BE DB. I suspect the Windows update somehow is causing this. I would like a true fix rather than having to do the daily shut-down/C&R. 

 

Answer 8

Hello James,

I still have not found a fix for our situation but good to know there are other "victims" out there.  :-)

---

Roget Luo

Answer 9

Well actually his case is different.

In your case you are sharing the same front end copy, and allowing multiple users into that one front end. Often a company will do this for some extended period of time, but then “boom” and we see all hell breaks loose.

So your case and the problem elimination has NOT started because you are allowing multiple users into that ONE front end. If you do that, you will OFTEN find problems like what you see.

The problem is if one workstation with a different update to office, or simply that one user has an “issue”, then everyone else will be blown out.

I mean, there is a REALLY good reason why we install software such as word, or Excel, or outlook on EACH workstation.

Now of course Word, or Excel etc. can “open” and “consume” some shared file on the network.

The issue here is that now YOU are the software developer – that means your “code part” or the so called “interface” part HAS to be installed on each workstation. I mean, imagine if one user has an issue with word, and now everyone else in the building can’t use word.

You have to realize that “most” software has two parts:

1)

The program part (user interface, computer code)

2)

The data file part.

Your issue and problems are VERY likely the result of attempting to share the program code part. I mean, even things such as setting a filter on a form/report can now effect other users. Such a setup is not workable, and bottom to dollars I am willing to be that near EVERY other software system you have is installed on EACH computer. Just because now you and your software team is building “in-house” software is not some reason to toss out how you install all other software.

So you need to setup some kind of “install” process or some means to place the FE on each workstation like you doing for all other software. Until such time you do this, then you going to have nothing but problems and the act of one user will effect and damage the operation of that great software you wrote for all other users.

You been lucky, and were able to get away running your system as you had, but as you can see now you’re paying that price.

So at this point in time, we really don’t know if your issue is the same as the other user – since they are running a split database, and MORE important they placed the working application on each workstation. So until such time you adopt that setup, we can’t really know if your issues are the same as that other poster.

The “simple” question is ask your IT department where they install all other software. Their answer will point you to what you need to do for your setup.

Regards,

Albert D. Kallal (Access MVP, 2003-2017)

Edmonton, Alberta Canada

Answer 10

DITTO here!

I have 20+ similar MS Access databases and usually get a corruption or "inconsistent state" issues on average once a year (between all of them - just one problem a year...maybe).  Over the past few weeks I have 5 clients that call me with this problem and all I have to do is open the backend database and allow windows to 'repair' it and it works again (for a day, or two, or maybe a week IF i'm lucky). I, like you, am scouring the internet for a solution.  It HAS to be a Windows Update that caused the problem!

Clues that I have (1) it will get corrupted by a user that's clicks a button that runs somewhat complicated code that updates tables in the backend and (2) seems to be corrupted first thing in the morning when the first user trys open the application.  Also, this is NOT happening when users use the application on a Terminal Server whereas ALL users are running the frontend and the backend in the same box.

The problem always occurs on small networks where the backend is hosted on a file server and the users ALL have their own frontend application.  PLEASE let me know if someone finds a solutions.   Thanks! Bill

Answer 11

Hi Bill,

Can you try the workaround described here: https://support.microsoft.com/en-gb/help/2957623/cannot-access-shared-files-or-folders-on-a-drive-in-windows-server-201

To see if that makes the problem stop?

Shane
Access Engineering

---

Shane L. Groff (Microsoft Engineer)

Answer 12

Still no solution in sight, however, after hours of testing, we figured out that its likely the Windows 10 creator update to Version 1803 is the cause of our problems.  Setup VMs and upgraded to the latest OS version and no Office patching, continue to experience "inconsistent state" issues when multiple users accessing the shared front end DB.  Then ran the same test with VMs on an older OS build, no issues!!  However, since Windows 10 deletes all previous restore points after a major update, we can't roll any of the machine back to previous version.

---

Roget Luo

Answer 13

Hi Roget,

Have you tried the workaround described here: https://support.microsoft.com/en-gb/help/2957623/cannot-access-shared-files-or-folders-on-a-drive-in-windows-server-201 ?

We do believe this is related to the issue described here in the Windows 1803 update, KB 4100403so you could also try the workaround suggested for that, which is to ensure that SMBv2 or SMBv3 is enabled on both client and server as described here KB2696547,

Let me know if you try either of those workarounds, and what results you see.

Thanks,

Shane Groff
Microsoft - Access Engineering

---

Shane L. Groff (Microsoft Engineer)

Answer 14

Hi Shane,

Thanks for the advice.  SMBv2 returned  "True" on both file server and client.  SMBv1 was enabled on the file server but not on the client. I'm a bit unclear on the work around, do I need to disable SMBv1 or just ensure that SMBv2 is running on both server and client?

Thanks. 

---

Roget Luo

Answer 15

We are also experiencing the same issue.   We are on a 2016 server.  Will those patches work on it or only 2012 R2?

Answer 16

Also experiencing this issue. We have a 2008 R2 server which has been hosting an Access database with separate front and back end files for many many years.

We map the network share containing both the front and back end to Z drive and put a shortcut to the front end on the desktop. This solution has been working for the last 8 years with Access 2007 running on Windows 7. We held off upgrading during the dark ages of Windows 8 and 8.1 but just did the upgrade to Windows 10 and Office 2016. 

We are running Windows 10 1803.

Are there any solutions to this problem? The office staff are having to load the backend and "repair" the database multiple times every day.

Answer 17

I double checked and we have SMBv2 enabled on both the server (2008 R2) and the client (Windows 10 build 17134.228)

Answer 18

I am getting something very similar. Half a dozen users each with their own front-end are opening a shared back-end database. This database has been functioning fine for several years. Since upgrading to Windows 10, we've been getting "this database is in an inconsistent state" messages pretty frequently. But today (and there was a system update last night), the database has become unusable since we've been getting the error several times a day.

This database is used by several people every day and is a critical part of our business operations. We have a plan to replace it with a SQL Server database but that is al least a year away. We need a solution and the quicker the better.

Answer 19

Hi,

the initial post in this thread is about a SQL Server backend. You seem to have an Access backend. If that's the case then it is a known problem.

The current situation is that there is still no real solution or fix. The only thing that works (almost) reliably is the workaround to turn off Leasing in the registry of every client and the server.

"Almost" refers to some reports that the registry key would have disappeared again after some update or didn't seem to work 100% in every situation. But in general it works albeit with possible drawbacks on the overall performance of the systems.

You can read more at Daniel's page or vote for one or the other UserVoice item.

---

Karl
http://www.AccessDevCon.com
http://www.donkarl.com

Answer 20

Thanks. Daniel's page seems to describe our problem to a tee. Unfortunately we are not in control of the network and it's highly unlikely our network team will want to make and changes to the registry on our servers. The latest error we got this morning was:

Answer 21

I tried moving the database to a different server and so far it has only crashed once, which is much less frequently than before. I'm hoping this good fortune continues because our Network team are not sympathetic to MS Access and just advise converting to SQL Server.

Does anyone know what operating systems this affects? Our network lady says the server is running Windows Server 2012.