Access Error 3343 Unrecognized Database Format: Repair a Corrupt ACCDB or MDB

Fix it now

The database engine read the front of the file and did not find something it recognises as a database. That is a header problem rather than a data problem, so the tables inside are often intact. Work on a copy, repair the copy, then import the objects into a fresh container and use that from now on.

1. Copy the file somewhere local and work only on the copy. Never troubleshoot the original, and never let a repair run against the only copy you have.
2. Look beside the database for a lock file with the same name and a .laccdb or .ldb extension. If nobody has the database open, delete it.
3. Start Access with no database open and run Compact and Repair against the copy, from the Database Tools group on the ribbon.
4. Whether or not that succeeds, create a new blank database and import the objects into it: External Data, New Data Source, From Database, Access, then select the tables, queries, forms and reports in groups.
5. If the import cannot see the objects either, stop and restore from your most recent backup. Everything after that point is guesswork with your data.
6. Once you have a working file, move it off whatever it was living on. An Access database belongs on a file share or a local disk, never inside a folder a cloud client is synchronising.

Check the file size before you spend an hour on it. A database of a few kilobytes is a download that never finished, and no repair recovers data that was never written.

If the recovered file opens and the record counts look right, take a backup and stop here. The next section explains what the engine objects to and why the same database keeps doing it.

Why it happens

Microsoft publishes no error-number reference for the Access database engine, so treat 3343 and its companions as labels rather than as defined meanings – the article’s own codes table says so for each of them. What the number tells you is where the engine stopped: at the front of the file, before it got as far as your data. An Access file starts with a header identifying the format, followed by a catalogue describing every object in it, and both are read before anything else happens. If the header bytes are not what the engine expects, or the catalogue points at pages that do not hold what it was told they hold, it stops there and says the format is unrecognised.

It cannot tell you why, because at that point it genuinely does not know. A truncated file, a file written by a newer engine, a file that is not a database at all, and a file whose first pages were overwritten all look identical from where the engine is standing. That is worth holding on to, because it stops you reading the message as a verdict on your data.

The most common physical cause is a write that did not complete. Access holds pages open and writes them incrementally, so the link between the client and the file matters far more than it does for a document. A database on wireless, on a VPN, or inside a consumer file-sync folder is exposed to exactly this. Sync clients are the worst of it, because they upload a file that is still being written and can put a half-written version back over a good one.

Full reference

What none of these codes are

Microsoft does not publish a meaning for 3343, 3049, 3011 or 3024. Pages that give you a confident one-line definition are repeating each other rather than the vendor. Describing them by what they stop you doing is honest and is enough to work with, and it keeps you from building a theory on a number somebody made up.

Recovering objects into a clean container

1. Create a new blank database of the same format.
2. Import in this order: tables first, then queries, then forms, then reports, then macros and modules.
3. Import in small groups rather than all at once, so a failure tells you which object caused it.
4. Skip any object that fails the import and note it; you can often rebuild one form faster than you can rescue it.
5. Re-create relationships and indexes, and check them against the original design before anyone uses the result.
6. Compact the new file, back it up, and only then let people work in it.

Why the same database keeps corrupting

• It is unsplit and several people open it at once, so every user’s session is writing to the same file.
• It lives in a synchronised folder, where a client uploads partial writes and can restore an old version over a newer one.
• It is reached over a VPN or wireless link that drops, which interrupts writes mid-page.
• Nobody compacts it, so it grows until it is slow enough to make a dropped session likely.
• There is no backup, which is not a cause of corruption but is what turns it into a disaster.

Splitting, and why it is not optional for shared databases

In a split design the tables live in one back-end file on a share, and every user runs their own local copy of the front-end holding the forms, reports and code. Only data crosses the network, each user’s interface objects are their own, and a client that drops takes far less with it. It also makes upgrades possible: you replace one front-end without touching anybody’s data. Any database more than one person opens should be split, and one that has already corrupted twice should be split this week.

Compact and repair rewrites the file in place. If it fails part way through you can be left with less than you started with, so run it against a copy and keep the original untouched until you have a result you trust.

Every code this article covers

Confirm the fix worked

1. Open the recovered database and confirm every table, query, form and report is present.
2. Compare record counts in the main tables against the last known good figures, not against what looks plausible.
3. Run compact and repair once more and confirm it completes without an error.
4. Open each form that writes data and save one test record through it.
5. Take a backup of the recovered file before anyone else is let near it.

Questions people ask about this