Database in Inconsistent State (1 Viewer)

[ErinL]

Hello all -

The past few weeks we have been seeing a couple error messages on three databases that are linked together. The message is either "Unrecognizable Database Format" or that the database is in an "inconsistent state". It happens on all three databases but not all at the same time.

I am able to fix the problem by having everyone log out of the databases/shut down their PCs and then doing a compact and repair on the database that is producing the error. The problem with that is that it stops the users from doing their work for 15-20 minutes while I get everyone out and do the repair. It may not seem like a lot of time but I work in a warehouse that has to get trucks out at specific times throughout the day and I try to disrupt their work day as little as possible so that everything runs on time.

Is there a specific reason that this is happening?

A little more background info... This mainly started happening more often (it is now basically a daily occurrence) when our company started migrating PCs from Windows 7 to Windows 10. All PCs should have Office 2013 on them now but there is a mix of Windows 7 and Windows 10 throughout the building.

I wondered if this was part of the problem. The good news is they are in the process of moving everyone over to Windows 10 and the conversion should be completed in the next couple weeks. If it is a result of multiple Windows versions we may be able to muddle through it until they are all complete but I'm not 100% sure that is the issue. We use other databases as well and they don't seem to have this issue. It's only the three that are linked and used by the most people.

Any light you could shine on this would be much appreciated.

Thank you in advance!

 

[Micron]

What version of windows and Access is the development and compact/repair being done on? Possibly missing/broken references between versions.

It's only the three that are linked and used by the most people

What does that mean? db is shared/not split?

 

[TraceSL]

Hi Erin
I am seeing some of the same type odd behaviors here as well. Be sure who is the developer of the systems is on a lower version (build of Windows and Access). The user computers should be at the same level or higher. That's my focus at the moment to stabilize our environment. Trace

 

[gemma-the-husky]

might be a problem from last year
Access – Bug – Database is in an Unrecognized Format

try this link

https://www.devhut.net/2018/06/13/access-bug-database-is-in-an-unrecognized-format/

 

[ErinL]

Thank you both for the quick responses.

I have been doing the repair on my PC which has been upgraded to Windows 10. Are you saying I should be doing the repair from a Windows 7 PC?

No. The databases are not split. I have looked into this but, to be honest, don't fully understand it and have never done it. From what I understand, the tables are all saved in the back end database and the queries, forms, reports, macros are all saved in separate databases that are saved on the individual PCs. Is that correct? I didn't understand this because if you make changes to a form or report you would have to change it on each PC rather than on the one database everyone uses. Do I have this wrong?

 

[Micron]

By your description it IS split.

Do I have this wrong?

Partially. You would ALWAYS have backup copies of front and back ends. Development is mostly fe stuff e.g. a new report. You distribute the fe to all users but there is so much info out there on various methods for doing this that it's too much to repeat here. The best ones require the user to effect the transition to the new fe version based on some startup compare such as a version number in be table (at least that's my take on it).

AFAIK, there is no guarantee that doing development in the oldest platform will fix all issues. Reference library versions could still be a problem, both from a version standpoint as well as library file locations from one windows install to another

 

[gemma-the-husky]

I don't think they ever truly got to the bottom of the reference I pointed out. It arose with the April 18 annual update. Databases reported inconstant state when they weren't, but you had to get everyone out, and then do a C&R.

By not splitting your databases you increase the risk of real corruption.

Also, if you have a the data and code in separate databases, it's easier to use the code against a "copy" of the data in order to develop and test additional functionality.

 

[TraceSL]

might be a problem from last year
Access – Bug – Database is in an Unrecognized Format

try this link

https://www.devhut.net/2018/06/13/access-bug-database-is-in-an-unrecognized-format/

Thanks good info

 

[Gasman]

I read the o/p's post as describing what they thought a split DB was, but not using split DBs themselves.?

By your description it IS split.Partially. You would ALWAYS have backup copies of front and back ends. Development is mostly fe stuff e.g. a new report. You distribute the fe to all users but there is so much info out there on various methods for doing this that it's too much to repeat here. The best ones require the user to effect the transition to the new fe version based on some startup compare such as a version number in be table (at least that's my take on it).

AFAIK, there is no guarantee that doing development in the oldest platform will fix all issues. Reference library versions could still be a problem, both from a version standpoint as well as library file locations from one windows install to another

 

[Micron]

I read the o/p's post as describing what they thought a split DB was, but not using split DBs themselves.?

you are probably correct. I took "the tables" to be "the tables in my db".
In that case, references are probably the least of their problems.

 

[The_Doc_Man]

ErinL - if you have not split the database, you only do yourself dirt because you will be facing corruption on a frequent basis. When you split things into front-end (FE) and back-end (BE), you reduce the odds of lock "collisions" that lead to corruption due to partial data updates that fail before they can finish - thus "inconsistent state."

Yes, everyone should have their own copy of the FE and each FE should map to the shared BE file. The most popular method seems to be that your users don't launch the FE file. They launch a batch job that copies the newest FE file from the common folder to the place where the batch job sits, then launches the new copy. That topic was explored in this thread.

https://access-programmers.co.uk/forums/showthread.php?t=86888

 

[ErinL]

Thank you for all the info. Looks like I will definitely be splitting the databases in the very near future.

Thanks to everyone for the assistance.

 

[RogerCooper]

I have some similar problems. Access's stability in a multi-user environment has declined in recent years due to OS changes. Here are some things that have helped me.

Overnight automatically copy the database to a new file and repair it.

Function CompactAndCopyBack(FileName As String, TempName As String)
On Error GoTo Handler
FileCopy FileName, TempName
Kill TempName
Application.CompactRepair FileName, TempName
FileCopy TempName, FileName
Exit Function
Handler:
End Function

Also try to see if there is a specific table that corruption originates in, probably a table which has the most frequent transactions. Put that table in its own database, and repair will be faster.