Unrecognized Database Format

[Quin]

I have a nifty Access file that contains a list of employees and their work
schedules. It is only about 400 records in total and is not connected to any
other database. I just did an update pulling table data from an Excel file
and replacing the existing table.

To share it with co-workers I have placed the main file on a common drive
and I emailed a link(shortcut) to about 100 co-workers.

When I tested the link on a co-worker's computer every thing was fine. Just
one day later I, and everyone else, get the error message "Unrecognized
Database Format" and the file will not even open to trouble shoot. The name
of the file is:

Employees_2007-2008.mdb

It worked under that file name for the last year so I think the file name is
ok. I think the link is ok too because I can go to the actual file on the
common drive and it reports the same error.

If I click on help I get the following suggestions:

Unrecognized database format (Error 3343)
Possible causes:

The specified file name is not a Microsoft Jet database.
The specified file name is a device name, for example, a printer or a
console.
The .mdb file has invalid header information or an unknown sort order.
A commit is pending from another user but the lock file cannot be found.
During a commit, you are attempting to write a Long value larger than the 2K
maximum page size.
The database is damaged. Compact the database and then try opening it again.

Most these suggestions are not helpful to me at my experince level. Seems
kinda tough if you can not open the program!

Any ideas on what I should try?

Quin

 

[Arvin Meyer [MVP]]

That is often a sign that the database is corrupt. It usually happens when
someone turns off their computer without closing the database first, or if a
network connection is broken. It also happens if the database is not split
and several users are sharing a front-end from the server. Do the following:

First, always work on a copy of the database. Working on the original may
make it impossible for a repair service to fix it.

Download a copy of JetComp.exe:

http://support.microsoft.com/default.aspx?scid=kb;EN-US;273956

Try backing up your forms as text with the undocumented SaveAsText
LoadFromText functions:

http://www.datastrat.com/Code/DocDatabase.txt

Also have a look at the Microsoft KB article:

http://support.microsoft.com/default.aspx?scid=kb;EN-US;209137

Then have a look at Tony Toews' Access Corruption FAQ at:

http://www.granite.ab.ca/access/corruptmdbs.htm

for some suggestions. Unfortunately, some corruption cannot be fixed - you
may need to create a new database, import what can be salvaged, and recreate
the rest.

Although it's a paid service, Peter Miller does an outstanding job of saving
corrupt databases. Try this URL:

http://www.pksolutions.com

 

[John W. Vinson]

To share it with co-workers I have placed the main file on a common drive
and I emailed a link(shortcut) to about 100 co-workers.

Urmph. That's a pretty much GUARANTEED recipe to corrupt a database. I hope
you kept a backup!!!

You should instead use the Database Splitter Wizard to split the database into
a shared backend, and distribute a .mde file of the frontend.

See http://www.granite.ab.ca/access/splitapp.htm

as a criterion.

 

[Quin]

Arvin, John,

Thanks for your quick reply's. I have been reading about "front end" and
"back end". This is a very simple access project. Just one table, one
Querry and one form. It is only used to "look up" employee schedules so no
one adds or removes any records. Also it is seldom used. No need for
multiple simultaneous access. The employees that use this all ready have
links to it on their computer and I’m not sure if sending them each a "front
end" is what I would want to do.

This is a long way to as my current question. Can I just set the "Default
open Mode" to "Exclusive" to eliminate a repeat of this problem after I fix
the file? I can repair it without too much trouble as I have a copy with old
data in it. All I have to do is import the new stuff from an Excel file.

 

[Arvin Meyer [MVP]]

Since you will need to set the Exclusive bit on every machine, it would be
just as easy to create a front-end and place a copy on the server, then drag
a copy to each user's desktop. At least then you will have done it properly.

 

[Quin]

This discussion is very helpful to me. I did not realize that exclusive
access would be required for each and every user on each and every computer.
I will see today if I can follow the directions to split this into front end
and back end. One question... I would like to continue using the current
short cut that has been established with all the current users. Will it work
to have that short cut point to the front end? I will just give the front
end the same name in the same directory on the common drive. Then in the
same directory on the common drive I will place the table and form.
Apparently just as long as it is "split" it will work. Do I have this
concept right?

I guess the alternative is to set the exclusive bit in code which would not
exactly be the best "right" way. And it would follow that I would need to
set the bit back to non exclusive upon exit to not screw up everyone's
default settings. (I am probably not up to that task anyway).

Quin

Quin

 

[Quin]

Here is an Update...

I got my file put back together. I kept the original name,
"Employees_2007-2008.mdb. I placed it in the common drive directory so the
existing links (employee shortcuts) will hook up to it. Then I ran the
splitter wizard. This gave me a file with the name
"Employees_2007-2008_be.mdb.

I now believe the "Employees_2007-2008.mdb file is correctly linked to the
"Employees_2007-2008_be.mdb file because it shows an arrow by the reference
to the table. However, I see that the form and querry does not have the
arrow and are probably not linked. Is this a problem and does it indicate
that I missed something?

Let me say thanks. This is great to know about this stuff...

Quin

 

[John W. Vinson]

I would like to continue using the current
short cut that has been established with all the current users. Will it work
to have that short cut point to the front end? I will just give the front
end the same name in the same directory on the common drive. Then in the
same directory on the common drive I will place the table and form.
Apparently just as long as it is "split" it will work. Do I have this
concept right?

Unfortunately - NO, absolutely NOT!

You are now getting the worst of both worlds: you have the possible
performance loss of a split database, but you're still sharing one and only
one frontend among all the users, giving you all of the contention, risk of
corruption, bloat and mutual interference that you had with a single database.

Each user *MUST* have their own individual copy of the frontend.

 

[Arvin Meyer [MVP]]

No. The reason you have corrupted the database is that multiple users are
sharing the same copy of the code. That is asking for data loss and form
corruption.

After splitting the front-end from the tables you MUST put a copy on each
users workstation. They should NEVER share the front-end. Shortcuts are
immaterial. You can just put the front-end itself right on the desktop.

If your users have a roaming profile, it might be better to put a shortcut
to somewhere on the C: drive where the front-end will reside. This is due to
the efficiency of shortcut over files when roaming profiles are used.
--
Arvin Meyer, MCP, MVP
http://www.datastrat.com
http://www.mvps.org/access
http://www.accessmvp.com

 

[Quin]

Ok...

So just to make sure I got this straight. I should remove the file,
Employees_2007-2008.mdb from the common drive, I should leave
Employees_2007-2008_be.mdb on the common drive and then I could email
everyone the actual Employees_2007-2008.mdb file.

Does it matter that Employees_2007-2008.mdb only links to a table and not
the form and query?

I do not go back to work until this weekend. Probably my file will crash by
then (again). I got it backed up a couple of different ways. (Is it
acceptable to just do a copy / paste for a backup?)

Thanks for your continued help,

Quin

 

[John W. Vinson]

Ok...

So just to make sure I got this straight. I should remove the file,
Employees_2007-2008.mdb from the common drive, I should leave
Employees_2007-2008_be.mdb on the common drive and then I could email
everyone the actual Employees_2007-2008.mdb file.

Just so "everyone" is on a fast, stable wired network. Wide Area Network and
wireless connections are not suitable.

Does it matter that Employees_2007-2008.mdb only links to a table and not
the form and query?

Employees_2007-2008.mdb should CONTAIN the form(s) and query (queries). That's
how it works. The data is stored in the backend in the table; the queries
selectively pull the desired records onto the user's computer; the Form (or
report) arranges the data in the query for display.

I do not go back to work until this weekend. Probably my file will crash by
then (again). I got it backed up a couple of different ways. (Is it
acceptable to just do a copy / paste for a backup?)

Copy/paste is fine *IF* nobody has the database open at the time. If the
databse is open, it's quite possible that you'll make a copy while somebody
has a transaction in process, and the database will be left in an inconsistant
state - and corrupted.

Thanks for your continued help,

Take a look at some of the links at:

Jeff Conrad's resources page:
http://www.accessmvp.com/JConrad/accessjunkie/resources.html

The Access Web resources page:
http://www.mvps.org/access/resources/index.html

A free tutorial written by Crystal (MS Access MVP):
http://allenbrowne.com/casu-22.html

MVP Allen Browne's tutorials:
http://allenbrowne.com/links.html#Tutorials

Tony Toews' resources website:
http://www.granite.ab.ca/access

Tony has some good links and resources on multiple-user split database
architecture.

 

[Tony Toews [MVP]]

I now believe the "Employees_2007-2008.mdb file is correctly linked to the
"Employees_2007-2008_be.mdb file because it shows an arrow by the reference
to the table.
Excellent

However, I see that the form and querry does not have the
arrow and are probably not linked. Is this a problem and does it indicate
that I missed something?

No. The form and query don't know or care that the table is linked.
Only the table knows about that.

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/