Printable Version of Topic

Click here to view this topic in its original format

UtterAccess Forums _ Network Issues _ Inconsistent State Error On Windows 10

Posted by: BuzyG Jun 18 2019, 05:29 AM

Hi All

We have been getting an random Inconsistent State Error, ever since we moved over to Widows 10, typically once or twice a day on our largest access data base. 50+ users typically several logged on at any one time. But also occasionally on databases where only one user is logged in.

databases are:-

Split FE & BE, I do not have access to users C: drives so have created multiple FEs in different folders on the shared drive. But it is possible for more than one user to log in to the same FE. This never once, in 15 years, caused a problem prior to Windows 10.

All users now on MS Access 2016. most on runtime but several with the full version.

The database files where .accdb
I have been through every line of the code, reworked the error trapping, removed previous old code, that was preventing full compile and now all the FE's are compiled .accde files. This was a lengthy but worth while exercise. Alas it appears it made no difference to the error.

With assistance from the package manager, responsible for MSAccess 2016, we have implemented the following on the server and on each user's desktop.

@echo off
title Babcock Access 2016 Leasing Fix


echo Applying Microsoft Access 2016 Leasing Registry Keys, please wait...

REGEDIT /S "%~dp0source\Access2016DB-Fix.reg"

echo Registry Keys applied successfully..


Alas none of this has had any noticeable affect on the error. So I'm here asking the guys who know Access Best. Any thing else we can try.

Posted by: Phil_cattivocarattere Jun 18 2019, 05:44 AM

But it is possible for more than one user to log in to the same FE.

This could be the main error cause.
Why this never happened in the past? You were lucky, I think.
It happens even when only one user is logged? The FE should be local, on the hard drive and not in LAN.
There should be a path where a user, in his own pc, can do "everything", with full control. Put the FE there. Ask your IT manager to know it.

Posted by: DanielPineault Jun 18 2019, 07:01 AM

It's a known bug that is now more than a year old that we are all awaiting a fix from Microsoft. You can learn everything there is to know about it and the only known "temporary" workaround by reviewing

It's actually a Windows 10 bug which impacts Access. Not Access' fault, but we are still the ones dealing with the issue.

But it is possible for more than one user to log in to the same FE.

This could be the main error cause.

Every user MUST have their own copy of the front-end.

Posted by: BuzyG Jun 18 2019, 07:15 AM

Hi Phil

We have no such accessible hiding place for local use. We did have once, but it went with windows7 implementation, many years ago. Since then users have been able to inadvertently share an FE, though they are informed enough that they should only log into an FE where there is no lock file active. I'm certain they still do though because they are human and they can.

I am working with the IS package manager, so I will ask if there is a way he can repackage this particular FE, to put it on each user C: drive.

Doesn't alter the fact that these issues never showed themselves in any previous version of windows. Therefore windows 10 is certainly playing it's part and quite rightly, IMHO, gets some of the wrap for these errors.

If this is not an option to me, is there anything else that I haven't tried that folk know of, in respect of this error.

Posted by: cheekybuddha Jun 18 2019, 07:21 AM

If each user can't have their own copy of the FE on their local HD, then the next best thing is to have their OWN copy of the FE on the network - do your users have their own folder on the network? If not, make folders for each user in a network share and place an individual copy of the FE in each. Then the users can open their copy of the FE.



Posted by: BuzyG Jun 18 2019, 07:28 AM

Hi Daniel

Yes indeed. We have had the error for a good few months ourselves and I have read up much on it. Including some of your own inputs thx. We still have no resolution though, so I thought I would post up here. This is by some way the most knowledgeable Access community I know of and you never know what fresh information, people such as your good self, may have found, since the last internet trawl.


Posted by: BuzyG Jun 18 2019, 07:32 AM

Hi Cheeky

Completely agree with your suggestion and will use if no other option available Though as mentioned by Phill, this does not fix the problem, as we are still working on a server 200 miles away. It merely reduces the likely hood.


Posted by: DanielPineault Jun 18 2019, 07:50 AM

Did you implement the Registry Hack?

we are still working on a server 200 miles away

So you are using Access over a WAN?! In that case, you need to use Terminal Services, CITRIX, Remote Desktop, ... Access, with each newer version, is more and more incapable to such feats. Personally, with such a setup, I'd be looking at another back-end immediately (SQL Server, SQL Azure, ...), if not completely switching away from Access to PHP/MySQL, .Net, ...

Posted by: cheekybuddha Jun 18 2019, 08:01 AM

>> we are still working on a server 200 miles away <<
Are you already using Citrix/thin client setup?

If not, then what Daniel said!!!

Posted by: BuzyG Jun 18 2019, 08:32 AM

Your replies read like the end of Access as we have known and loved it for 30 odd years.

Thus far we have spent close to 7 figures, just on this site, trying to implement, within a shared world wide, corporate solution, what a few smaller access databases used to do effortlessly, but locally. Current target is to complete within three years. Until then I have the task of keeping them going, with an ever growing list of users and projects and another multinational, Microsoft who clearly don't see a future for Access either frown.gif. I did at least have the pleasure of creating them in the first place. smile.gif

Thx for your replies. I will keep an eye out for any more ideas here.

Posted by: DanielPineault Jun 18 2019, 08:43 AM

Nothing has truly change on the Access front. It was never meant to be used over a WAN (Albert Kallal has an excellent article on this which has been around for 10-20+ years now) and you're never supposed to share a common copy of a front-end with multiple users. It's absolutely amazing that you didn't encounter serious issues prior to this. But yes, this latest Windows 10 bug is an absolute show stopper if you are impacted by it. The workaround (disable leasing) works, but many experience some network performance reduction.

with an ever growing list of users

This may be part of your issue as well. If the number of users has increased, you may have finally hit the breaking point of Access on your WAN.

Terminal Services and CITRIX remain 2 great options IMHO, or migrating the back-end to SQL Server/SQL Server Express and would give you a lot more stability (well outside of the Microsoft bugs! - <deep breath here/>).

Good luck.

Posted by: BuzyG Jun 18 2019, 10:34 AM

Your absolutely right Daniel. I was expecting trouble when we switched from XP on the old LAN to windows7 on the WAN. Prior to that users each had their own FE on there C: drive. The Way the WAN is implemented effectively forced the set up we have now. There are multiple FE's but I have no means to police if they are used correctly. However we got away with it on Windows 7 and had already started to look at replacing Access, for these specific applications. Windows 10 though has come along before a replacement is up and running. So we just have to deal with it for now, until we can switch the data over to the new solution, At least this has generated increased impetus for that solution.

I hadn't really thought much about an interim solution, but will forward the CITRIX Terminal suggestion. I recall it has been muted before internally here. No harm in asking again, now we actually have a real issue to sort out.

Posted by: BuzyG Jun 20 2019, 02:40 AM

I received this from our IS Package managed this morning.

Currently the database is stored on the P Drive which is a NAS Server running Linux so it does not have a Windows Registry to change. I am assigning the ticket over to Infrastructure Applications to have a look to see if it is possible to move this Database to a Windows server somewhere and then you would have to access it via a UNC path.

Has any one had this situation? Does any know, if this is likely to improve things?

Otherwise I guess we will try it and find out.

Posted by: DanielPineault Jun 20 2019, 05:02 AM

NAS devices are finicky when it comes to Access databases. Some work, some don't. But if it was working, I wouldn't be trying to switch it, at least not immediately. I'd apply the workaround disable leasing registry hack to the individual PCs and see if that does anything to help with the situation. Based on my experience, I don't think it will be enough (I've always needed to apply the fix to the server as well), but definitely worth trying. Also, most NAS devices do have management panels that enable all sort of configuration.

As for migrating from Linux to Windows and using UNC... You should always be linking tables using UNC, so nothing wrong there. Switching to Windows, I don't really see this as improving thing. It won't hurt, but the issue remains that there is a bug in Windows 10, so until the 'fix' is applied to each PC and the server, you will have the problem. Switching to Windows will not solve the issue just like that, they will have to implement the reg fix. Windows server will also not do anything to the limits of Access or improve bandwidth usage/network saturation/... It may however open door for say having access to CITRIX... It all depends on what direction the are trying to go.

Posted by: cheekybuddha Jun 20 2019, 05:23 AM

Reading through all this, I think migrating your backend(s) to SQLServer would be the least painful option. It will reduce latency and avoid this inconsistent state error.

You may have have to tweak the front-ends slightly, but probably not that much, and well within your capability.



Posted by: DanielPineault Jun 20 2019, 06:52 AM

cheekybuddha brings up a good point. SQL Server is definitely worth consideration as Microsoft shows no signs of fixing this year old bug any time soon, even more so if you already have it in-house.

Posted by: CaptainMilly Aug 14 2019, 06:47 AM

I do not have access to users C: drives so have created multiple FEs in different folders on the shared drive.

when you say you do not have access to the C drives, do you mean you just can't see them or the users can't access them either?

We used to have multiple FE's on the shared drive and it was a pain to update for me, so I have found some auto update code off the internets and now I do not need to have access to the users PCs or maintain individual share drive folders, I just place a single master copy on the share drive when there is an update and the users's desktop copy automatically checks if there is a new version and takes a copy of that if update is required. This also helps with user experience. I don't remember the exact web-page, but this is in the code disclaimer:

Created by       : Re-written by Scott L Prince; Original code Bob Larson
' Parameters       : None
' Result           : Determines if backend can be reached, and if front end is the current version.
' Returns          : 0 - Misc Error
'                  : 1 - No current version found in Version Manager file
'                  : 2 - Front end being run from master location
'                  : 3 - Master file path not found in Version Manager file
'                  : 999 - Front end current
' Date             : 5-30-14
' Remarks          : Based on previously-existing code by Bob Larson posted at StackOverflow