"Unrecognizable database format"

[bCloud9c via AccessMonster.com]

I have an access database in which the front end resides on each users
desktop and the back-end is on a shared network drive. The database has been
running great for months, until about a week ago. I started to get the run
time error message 3343 "Unrecognizable Database Format". So, the first few
times I got the error, I simply made a copy of my backend, compacted and
repaired it, and relinked my front ends to the new back-end. Well, now I'm
getting this error up to 5 times per day!!!!! Every time this happens every
user has to log out and wait until I compact and repair the database and
relink it - not to mention, I'm sure that some data is going to slip through
the cracks at some point.

The strange thing is that I have 3 or 4 other databases that are set up
exactly the same way as the one that is constantly corrupting........ same
users, same network drive, same Access Version ( 2000 by the way) etc......
and those databases never get this error. I would greatly appreciate any
advice you can lend. Thanks!

 

[Allen Browne]

Work through the list of items in this article:
Preventing corruption
at:
http://allenbrowne.com/ser-25.html

Don't skim on checking things like the JET versions are the same on all
machines, Name AutoCorrupt is off in both the front and back ends,
minimizing references and the decompile of the front end. If you are not
using an MDE for the front end, that will keep it from decompiling itself.

 

[bCloud9c via AccessMonster.com]

It is only my back-end that is corrupting. No one is ever actually in the
back-end, they are just linked to it from the front end on their desktop.
But when the back-end corrupts and I get the 3343 error message, I can't
compact and repair that version of the back end because it says someone is
still connected. So I have to copy it, compact and repair the copy, and
relink the database to the new back end. Could that help to narrow down the
possibilities of what is causing the corruption?

Work through the list of items in this article:
Preventing corruption
at:
http://allenbrowne.com/ser-25.html

Don't skim on checking things like the JET versions are the same on all
machines, Name AutoCorrupt is off in both the front and back ends,
minimizing references and the decompile of the front end. If you are not
using an MDE for the front end, that will keep it from decompiling itself.

I have an access database in which the front end resides on each users
desktop and the back-end is on a shared network drive. The database has

[quoted text clipped - 19 lines]

and those databases never get this error. I would greatly appreciate any
advice you can lend. Thanks!

 

[Tony Toews]

I have an access database in which the front end resides on each users
desktop and the back-end is on a shared network drive. The database has been
running great for months, until about a week ago. I started to get the run
time error message 3343 "Unrecognizable Database Format". So, the first few
times I got the error, I simply made a copy of my backend, compacted and
repaired it, and relinked my front ends to the new back-end. Well, now I'm
getting this error up to 5 times per day!!!!!

It is possible that there is some residual corruption left behind
after you do a compact and repair. Try importing into a new MDB.

Use the sysrels utility at the following location to copy the table
relationships layout window
http://www.trigeminal.com/lang/1033/utility.asp?ItemID=12#12
Or use Save Restore Modify Relationship Window at
http://www.lebans.com/saverelationshipview.htm

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

 

[bCloud9c via AccessMonster.com]

I have already tried importing everything into a new database and that did
not solve the problem.

I have an access database in which the front end resides on each users
desktop and the back-end is on a shared network drive. The database has been

[quoted text clipped - 3 lines]

repaired it, and relinked my front ends to the new back-end. Well, now I'm
getting this error up to 5 times per day!!!!!

It is possible that there is some residual corruption left behind
after you do a compact and repair. Try importing into a new MDB.

Use the sysrels utility at the following location to copy the table
relationships layout window
http://www.trigeminal.com/lang/1033/utility.asp?ItemID=12#12
Or use Save Restore Modify Relationship Window at
http://www.lebans.com/saverelationshipview.htm

Tony

 

[Allen Browne]

The corruption is most likely caused by an interrupted write.

That can be anything from bad power, or inconsistent versions of JET,
through to a particular user who is crashing out (Ctrl+Alt+Del), a bad
network card, or the kind of corruption that is caused by the front end
decompiling (and fixed with an explicit decompile, compact, and create MDE
for front end.)

It is worth the effort to work through the list.

--
Allen Browne - Microsoft MVP. Perth, Western Australia.

Reply to group, rather than allenbrowne at mvps dot org.

It is only my back-end that is corrupting. No one is ever actually in the
back-end, they are just linked to it from the front end on their desktop.
But when the back-end corrupts and I get the 3343 error message, I can't
compact and repair that version of the back end because it says someone is
still connected. So I have to copy it, compact and repair the copy, and
relink the database to the new back end. Could that help to narrow down
the
possibilities of what is causing the corruption?

Work through the list of items in this article:
Preventing corruption
at:
http://allenbrowne.com/ser-25.html

Don't skim on checking things like the JET versions are the same on all
machines, Name AutoCorrupt is off in both the front and back ends,
minimizing references and the decompile of the front end. If you are not
using an MDE for the front end, that will keep it from decompiling itself.

I have an access database in which the front end resides on each users
desktop and the back-end is on a shared network drive. The database has

[quoted text clipped - 19 lines]

and those databases never get this error. I would greatly appreciate
any
advice you can lend. Thanks!

 

[bCloud9c via AccessMonster.com]

Even though I have the front end on each user's desktop, an MDE would be a
possible solution to my problem? Could you explain in more detail how an MDE
is less prone to corruption than an MDB? I'm just trying to understand all
this stuff. Thanks.

The corruption is most likely caused by an interrupted write.

That can be anything from bad power, or inconsistent versions of JET,
through to a particular user who is crashing out (Ctrl+Alt+Del), a bad
network card, or the kind of corruption that is caused by the front end
decompiling (and fixed with an explicit decompile, compact, and create MDE
for front end.)

It is worth the effort to work through the list.

It is only my back-end that is corrupting. No one is ever actually in the
back-end, they are just linked to it from the front end on their desktop.

[quoted text clipped - 21 lines]

 

[Allen Browne]

The MDE is only one of many things, and not the top of the list.

Anything that interrupts the write is likely to corrupt the database. That
could be a user, power, bad hardware, other bad software, bad network
card/switch/connection, etc.

It could also result from an old version of JET on one of the machines that
is interacting incorrectly with the more mature service packs for JET 4. We
take this issue seriously enough to show the version of JET 4 on the Help |
About screen of all our databases, so the end user who is having problems
can tell us which one they are using.

There are other possible causes, as explained in the article, including
failing to explicitly save, and inconsistencies between versions.

One of those lesser issues is that every version of Access uses a different
binary for the compiled (machine) code. The MDB contains 2 versions of the
code:
- the text version (what you see and edit);
- the compiled version (what actually executes.)
Not infrequently, these two get out of sync. Symptoms include weird errors
that are version dependent (or even subversion dependent), bloating, break
points that no longer break, deleted code that still executes, naming
clashes that make no sense, other corruptions of the front end, and so on.
Explicitly decompiling instructs Access to discard the compiled version. It
then receates it from the text version, and so the sync error is gone. Using
an MDE prevents it from decompiling, as it has only the compiled version.
This is particularly useful where some users are on A2000, and others on
2002 or 2003.

Again, you need to investigate the other issues first.

--
Allen Browne - Microsoft MVP. Perth, Western Australia.

Reply to group, rather than allenbrowne at mvps dot org.

Even though I have the front end on each user's desktop, an MDE would be a
possible solution to my problem? Could you explain in more detail how an
MDE
is less prone to corruption than an MDB? I'm just trying to understand
all
this stuff. Thanks.

The corruption is most likely caused by an interrupted write.

That can be anything from bad power, or inconsistent versions of JET,
through to a particular user who is crashing out (Ctrl+Alt+Del), a bad
network card, or the kind of corruption that is caused by the front end
decompiling (and fixed with an explicit decompile, compact, and create MDE
for front end.)

It is worth the effort to work through the list.

It is only my back-end that is corrupting. No one is ever actually in
the
back-end, they are just linked to it from the front end on their
desktop.

[quoted text clipped - 21 lines]

any
advice you can lend. Thanks!

 

[wab]

,,,,,,,,,,,,,,,,,,,,,,,,,,,,