Back end Database Problems - Data base in an Inconsistant state

[Jens]

I have split my database into a front and back end, back end is on the server
and the front end is distributed amongst four seperate workstations so as we
can access and update our job booking data.

Occasionally I get the message that the database is in an inconsitant state.
I check our main table in the back end and the primary key for our job
booking table is no longer acctive and a couple of the other fields that I
have indexed and set to no duplicates are also inactive.

Any help would be greatly appreciated.

 

[John W. Vinson]

I have split my database into a front and back end, back end is on the server
and the front end is distributed amongst four seperate workstations so as we
can access and update our job booking data.

Occasionally I get the message that the database is in an inconsitant state.
I check our main table in the back end and the primary key for our job
booking table is no longer acctive and a couple of the other fields that I
have indexed and set to no duplicates are also inactive.

Any help would be greatly appreciated.

Your backend database is becoming corrupted. I hope you have good backups!!

See http://www.granite.ab.ca/access/corruptmdbs.htm for possible causes and
cures of corruption. Be sure you start with a clean database, well backed up;
compact and repair it as needed; be sure that your workstations are attached
by good, solid network connections (wireless connections are NOT good or solid
unfortunately).

You may want to consider moving the backend to SQL/Server.

 

[Jens]

Inactive means that when I have had a look at our job booking table in design
view, there is no longer a primary key associated with the table.

 

[Jens]

The back end is still good after repair, I have had to reassign the primary
key to the correct field, its not the first time that Ive had to do this. You
have sujested finding out the cause of the corruption, users are not turning
off the power, we do not have a wireless network and I am unsure how to check
if our network is unstable?

All users are using the current versions of Access 2007 on windows vista
platform.

 

[David W. Fenton]

You've eliminated the usual suspects. The network guys from your
IT department would need to test the network's stability.

I would beg to differ. You first need to eliminate potential
problems in the software ecosystem, such as AV programs, or hotfixes
to the server where the back end is stored.

 

[Tony Toews [MVP]]

Jet 4 sp8 ... are the latest for Access 2000 through 2008 on Windows XP.

There have been several msjet40.dll security patches since Jet 4.0 SP8
so the version number will be different. And just to screw people up
there are different versions of msjet40.dll for Windows Server 2003
for folks running Terminal Server and likely for Windows Vista.
Although I suspect the compiled code is virtually identical.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

 

[Tony Toews [MVP]]

You've eliminated the usual suspects. The network guys from your IT
department would need to test the network's stability.

The other problem is that intermittent hardware connections that fail
for only a few seconds seem to be a significant cause of corruption.
And no IT department on this earth would ever locate such.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

 

[David W. Fenton]

There have been several msjet40.dll security patches since Jet 4.0
SP8 so the version number will be different. And just to screw
people up there are different versions of msjet40.dll for Windows
Server 2003 for folks running Terminal Server and likely for
Windows Vista. Although I suspect the compiled code is virtually
identical.

The service pack number is the first digit of the build, e.g,,
msjet40.dll with version 4.0.9511.0 is service pack 9. The last 3
digits of the build number could differ, of course.