Any way to repair database that won't open?

[Magritte]

I have a database (.accdb) that when I try to open it I get the following
error:

Record(s) canot be read; no read permission on 'MSysObjects'.

After clicking on OK I get another error:

Record(s) canot be read; no read permission on 'MSysACEs'.

After clicking on OK again the database opens but is completely empty: all
the tables and queries are gone permanently and the 1 GB file is reduced to
around 300 KB, requiring me to copy it from a backup if I want to try again.

I've also tried using the Compress function in Access 2007 but when I run
that it gives me the same errors and produces the same empty database.

I have other databases that are linked to tables in the corrupted database
and when trying to open one of the linked tables I get an error saying the
database is locked because it is being used by someone else.

Fortunately, system restore saved an older version which is only missing a
couple of tables that I can re-import if necessary, but it would be nice to
be able to open the latest version to at least see the list of tables/queries
to make sure I'm not missing anything when I re-create it.

I did a search but only found a number of commercial programs and I don't
really want to spend $100+ to fix this one file.

Any suggestions?

Thanks.

 

[Magritte]

Your system tables appear to be currupted. Create a new db file and import
the tables and other objects from your backup, then compile the code and
compact the new db.

Chris

When I attempt to import tables from the corrupted database I get the same
errors and file is destroyed as described above for when I attempt to open
it. I guess I'll just have to live with the previous version. It's a shame
Microsoft does not have a repair tool. If I didn't have a relatively recent
backup I'd be very upset...

Thanks!

 

[Magritte]

Microsoft has 2 repair tools. Jetcomp.exe and the compact/repair tool you
use within Access.

Chris

From what I read after googling the Jetcomp.exe utility it sounds like it
might work. The normal compact/repair apparently tries to open the database
first which is proably why it fails to work.

However, the only version of Jetcomp.exe I was able to find is not
compatible with Access 2007 .accdb database format. Is there a newer version
I've failed to find?

Thanks!

 

[Magritte]

When dealing with databases always make sure you have a recent backup.

I think this is very good advice! I'm going to start backing up much more
regularly.

 

[John W. Vinson]

However, the only version of Jetcomp.exe I was able to find is not
compatible with Access 2007 .accdb database format. Is there a newer version
I've failed to find?

Not to my knowledge, unfortunately.

 

[John W. Vinson]

I think this is very good advice! I'm going to start backing up much more
regularly.

Yep. The only database that doesn't need to be backed up is one that you're
willing to recreate from scratch (at the most inconvenient possible time).

 

[David W. Fenton]

When dealing with databases always make sure you have a recent
backup. Access isn't the only database product that gets corrupted
db files. Googling corrupt sql server database returns 3 million
hits. Googling corrupt oracle database returns 359K hits. It's
that common with db files.

Yes, but with server databases, you can rollback to the last good
backup and then re-run the transaction logs. There is no way for Jet
to ever have transaction logs (because there's no centralized server
process through all commands would need to pass), so Jet will always
be less recoverable than server databases.

This is not to say that restoring a database in that fashion is fun
-- it categorically is *not* -- but at least the possibility is
available.

 

[David W. Fenton]

I think this is very good advice! I'm going to start backing up
much more regularly.

Also, make sure you have a multiply redundata backup strategy, and
that any backups that are stored in some proprietary format are
restorable.

Nobody ever loses data when they have a good backup. But people
frequently lose data when the backup they were depending on turns
out to be bad, or they were backing up the wrong data (like the
long-ago client of mine who was backing up the front end and not the
back end!).

I don't know if made the news, but a couple of years ago the tram
from Manhattant to Roosevelt Island broke down, and the passengers
had to be rescued with a small electric-powered bucket that
travelled up the cable to the suspended tram car and took out a few
passengers at a time.

The tram motors had two backups, but one of the backups was out
being serviced. Then the main motor failed, and when they swapped in
the first backup, it failed, too. Had the second backup not been out
being serviced, it probably would have worked.

But that backup was out of commission.

I think that teaches a really good lesson about multiply redundant
backups -- things never go wrong until the worst time.

 

[Tony Toews [MVP]]

Also, make sure you have a multiply redundata backup strategy, and
that any backups that are stored in some proprietary format are
restorable.

And are off site in the event of a flood, tornado, fire or similar.
Two clients of mine got a direct hit from the 1989 Edmonton F5
tornado. The large safe of the one client, about 6' wide 3' deep and
6' tall got shifted 100 yards. It was twisted so they had to get
hydraulic rams to square it up before the doors could be opened.

They got a phone call several months later from a farmer stating he
found a filing cabinet full of their paperwork in his field and would
they come and pick it up. It was about 30 miles away. By sheer
coincidence about ten years later I got to chatting with a woman who
turned out to be the farmers wife.

Etc, etc, etc.

Tony

 

[Larry Linson]

Some years ago, I was called in to a client shop... they had been
"successfully" backing up an old Access database for years and years, and
had several generations of backup tapes. The only thing they hadn't done was
to test to make sure the backup would restore. Turned out, it would not. I
was able to extract most of their recent data from a copy, and the older
data really was not necessary for their application to keep their business
going.

Larry

 

[Magritte]

Also, make sure you have a multiply redundata backup strategy, and
that any backups that are stored in some proprietary format are
restorable.

Thanks for the suggestions. My databases are local only and currently
I'm using Windows 7 backup for daily automated backups of changes and
manually starting backups after any major change. I also sync all
files between my desktop and laptop then also do a backup of the
laptop at a second location. So hopefully should something bad happen
there will be a relatively recent copy someone. But you bring up a
good point which is I haven't tried actually restoring the files, so
I'll do that. In fact, when I tested out the last version of Windows
backup (in Vista) I found that it was useless as it was great at
backing up but completely unable to restore even on the same hardware.
I've been working under the assumption that the quality of their
backup software could only improve that their file backup is more
robust than their system backup. However, given that I'm dealing with
Windows, some or all of those assumptions are clearly dangerous...

Thanks!

 

[David]

When dealing with databases always make sure you have a recent backup.
Microsoft has 2 repair tools. Jetcomp.exe and the compact/repair tool you
use within Access. Even if you don't get the data than you need to repair
your database with third party tool. Try
http://www.repair-access-file.com/download-access-file-recovery.php

 

[Tony Toews [MVP]]

When dealing with databases always make sure you have a recent backup.
Microsoft has 2 repair tools. Jetcomp.exe and the compact/repair tool you
use within Access. Even if you don't get the data than you need to repair
your database with third party tool. Try
http://www.repair-access-file.com/download-access-file-recovery.php

Ah, you are an employee of that company are you?

For more information on corruption including possible causes,
determining the offending PC, retrieving your data, links, official MS
KB articles and a list of vendors who state they can fix corruption
see the Microsoft Access Corruption FAQ at
http://www.granite.ab.ca/access/corruptmdbs.htm

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a free, convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/
Granite Fleet Manager http://www.granitefleet.com/