What “unrecognized database format” checks before it refuses the file

What the message checks

Access does not open a database and then discover a problem. Before it reads a single table it reads the first block of the file and compares it against a fixed pattern: four bytes 00 01 00 00, followed by the text Standard Jet DB for the older .mdb formats, or Standard ACE DB for .accdb. If that pattern is not where it expects it, the file is refused with unrecognized database format. None of your tables have been looked at yet.

The message reads like a verdict on your data. What Access checked was the first few dozen bytes, and five common causes make those bytes fail to match. Two of the five leave every row in the file intact.

The five causes, in order worth checking

1. It is not an Access file any more

A file can carry the .mdb extension and hold something else entirely: an Excel workbook someone renamed, a Zip archive, a text export, or a copy that was overwritten by a sync client. Access checks the signature, not the extension, which is why this case produces the error instead of opening garbage.

Look at the first bytes. A healthy Jet or ACE file starts with 00 01 00 00 and the words Standard Jet DB or Standard ACE DB beginning at byte 4. If byte 0 starts with PK you have an archive; if it starts with D0 CF 11 E0 you have an OLE compound file, the container Access 2.0 and earlier wrote, or an embedded object saved under the wrong name. Neither is something a modern Access will open as a database.

2. The file was written by a newer Access than the one opening it

This is a version mismatch, and it leaves the file untouched. An .accdb covers five Access releases, and each writes its own version byte into the same header position. An installation that predates the file refuses it with this message rather than a warning about versions.

The mirror case is an .mdb from Access 97 opened by an add-in or a script that expects Jet 4. The reader is older than the writer, and nothing is wrong with the file.

3. The beginning of the file was lost

If the first bytes are gone (truncated during a copy, clipped by a storage device, or dropped by a network layer), the signature is still present in the file, only earlier than expected. Everything after it has shifted, so every page boundary is wrong, and Access reports the file as unrecognized because it is looking at the wrong place for a valid header.

This case is partially recoverable. Our engine looks for the signature in the first 256 bytes, works out how many bytes are missing (between 1 and 13, the length of the leading pattern), and shifts the whole page grid back into alignment before parsing. The shift handles one specific injury. When a file has that injury, a copy the desktop tool refuses can still hand over its tables.

4. The file is encrypted, or carries a database password

Two unrelated things get called “a password” here. An encrypted .accdb is encrypted with Agile, RC4 CryptoAPI, or AES depending on the Office version, and without the password the bytes are noise. A Jet .mdb database password is not encryption at all: it is a field in the header at offset 0x42, and the file reads fine once the right value is supplied.

If the file is encrypted, no viewer, hex tool or recovery utility will read it without the password. Anything claiming otherwise is either decrypting Office’s container with a known weakness or not telling you the truth. Recover the password first, or the file stays closed.

5. The copy never finished

Sync clients and download managers are a steady source of this error: a zero-byte file, a file that stops mid-page in a OneDrive or Dropbox folder, or a “conflicted copy” whose name includes a computer name. Check the size against the original first. A 0 KB file holds nothing to recover.

Reading the version byte yourself

Byte 0x14 (twenty in decimal, the 21st byte) is the engine version. This is the mapping our engine uses when it decides which page layout and which text collation to apply:

Two branches matter here. If the byte is one of the seven above and the signature is in place, the structure is recognizable and the problem sits elsewhere: permissions, a lock, a missing library. A value like 0xFF points at a header that was overwritten, not at a file written by a future Access.

A ten-minute order of checks

1. 1

   Check the size and the first four bytes

   Zero bytes means an unfinished copy: go back to the source. Correct signature plus a plausible size means continue below. A different signature means the file is not what its extension says.

2. 2

   Read byte 0x14 and compare it with the Access you have

   A byte newer than your installation explains the error completely, and the fix is to open it on a newer machine (or have the data exported from it), not to repair anything.

3. 3

   Try the file on a second machine, from a local folder

   Copy it out of any sync folder, network share or mounted archive to a plain local path first. This single step rules out the network layer and the sync client, which account for a large share of the cases that look like corruption.

4. 4

   Ask whether the file is encrypted

   If the same file opens elsewhere with a password prompt, you have your answer. No recovery step applies until the password is known.

5. 5

   Only then treat it as damage

   When the signature and version are right but the file still fails, the injury sits inside the page structure. A reader that parses tables directly, instead of asking Access to open the database, can still get data out of it.

When the wording is slightly different

The same underlying refusal shows up in several shapes, and people search for the exact string on their screen. They are not all the same problem:

If the message is the third one, the diagnosis in the read-only and locked guide covers it: a file that cannot be opened because of permissions produces the same vague wording as a file that cannot be opened because it is damaged, and the two need opposite responses.

What Compact and Repair cannot reach

Compact and Repair is two operations sharing one button: it rewrites the file to reclaim space, and it tries to rebuild the internal structures Access uses to find your data. It works through Access’s own page reader, which means it inherits the same limits. If the header is rejected, compact cannot start at all. If the catalog is damaged, it has nothing to enumerate.

There is a second, more practical problem: it rewrites the file in place. Running it repeatedly on your only copy, hoping a later pass behaves differently, is the most reliable way to convert a recoverable database into an unrecoverable one. Work on a copy, and run it once.

What this tool can tell you first

The check on this site reads the file in your browser with a WebAssembly build of the same engine, so it does not need Access, and it does not need the file to be openable by Access. It reports what it found per table: the row count the database itself declares, the rows it read back, the rows it reached but could not safely parse, and the rows it never reached. Ten real rows are shown before you decide anything.

The report gives counts, not a percentage. A percentage needs a denominator, and the case with no denominator is the one worth seeing: a database whose table definitions are damaged declares nothing to measure against. The report then says the count is unknown rather than leaving the table out.