1. Triage the original
We confirm whether this is a version, provider or format issue or real corruption, and where the damage sits. That decides everything else, and it costs you nothing.
Access error 3343
Access “Unrecognized Database Format”: Fixed-Scope Recovery
The same message can mean a version mismatch or real damage. We confirm which, then recover with a written fixed-scope quote—typically from $1,200—working only on copies.
File will not open and the team is stopped? Call +1 385 386 3860 before anything else rewrites the file.
Call us at +1 (385) 386-3860
- DiagnosisVersion issue or real corruption, confirmed first
- AssessmentFree, and usually same business day
- HandlingWe work on copies, never your original
Quick answer: Access error 3343 (“Unrecognized database format”) means the engine could not read the file header. Often the file is healthy but opened in an older Access version or with the wrong provider; if it fails on every PC, the structure was damaged mid-write. Excel Access Expert recovers these as a fixed-scope project—free assessment, written quote typically from $1,200, work on copies only. Copy first; do not run repair tools on your only original. Recurring network damage often ends with Access to SQL Server migration; for keep-or-move after recovery, use our MS Access consultant.
Access recovery specialists since 2011 (15+ years). Last updated October 22, 2026.
Access shows the message, the file stays shut, and nobody can work. Before anything else, make a copy of the file and put it somewhere safe. Almost every unrecoverable case we are sent became unrecoverable after the original was rewritten by a repair attempt, not from the original damage.
What “unrecognized database format” actually means
Every Access database (.accdb or .mdb) begins with a header that tells the database engine which format and version it is dealing with. When Access, or any program using the Access engine, opens the file, it reads that header first. If the header is missing, damaged, from a newer or much older format than the engine supports, or read by the wrong engine, you get the message Unrecognized database format followed by the file path. Developers see the same condition as run-time error 3343 in DAO. Outside the US the message is often searched as “unrecognised database format”, and it is the same error.
The key point is that the message tells you nothing about why. A healthy file opened with the wrong tool and a genuinely damaged file produce identical text. That is why the first ten minutes should be spent telling them apart, not repairing.
The seven causes, and which ones mean the file is actually damaged
Causes 1 to 3 are compatibility problems. The file is fine. Causes 4 and 5 are about the file you are holding not being the file you think it is. Only causes 6 and 7 are real damage. Working through them in order is the cheapest route to the answer.
| # | Cause | How it shows up | Is the file damaged? | First move |
|---|---|---|---|---|
| 1 | File is newer than your copy of Access | One PC opens it, another says unrecognized format. Often follows a Microsoft 365 update or a file from a client. | No | Open it in the newest Access available. Do not run a repair tool. |
| 2 | Wrong provider or driver in code | Access opens the file fine, but Excel, Power Query, Python, .NET, VB6 or classic ASP reports the error. Usually Jet 4.0 pointed at an .accdb file. | No | Switch to the ACE provider or the Access ODBC driver (details below). |
| 3 | Very old format (Access 97 or earlier) | A legacy .mdb that current Access builds will not open directly. | No | Convert it through an older Access version, or send it to a specialist. |
| 4 | Wrong extension or not a database | A renamed file, an export that was never a database, or a web page saved as .accdb. | Not a database | Check the file header (script below). Look for the real file. |
| 5 | Incomplete or conflicted copy | Zero or tiny file size, an interrupted download or email, a sync conflict copy from OneDrive or Dropbox. | Copy is bad; source may be fine | Compare size with the source and re-copy. Check sync version history. |
| 6 | Structure damaged during a write | Starts after a network drop, crash, sleep or power cut while the file was open. The header still reads as Access. | Yes | Stop opening it. Work on copies. Restore from backup or recover. |
| 7 | Header overwritten or file encrypted | No Access signature at the start of the file. Often follows ransomware or a failed disk or storage event. | Yes, severely | Isolate the machine. Look for backups and snapshots first. |
Version mismatch: the most common false alarm
When one person updates Microsoft 365 ahead of everyone else, or a client sends a file saved by a newer build, older copies of Access can refuse it. Newer-only features, such as the Large Number data type introduced in recent Access builds, can make a file unreadable to older versions. Nothing is damaged. Running a repair tool on a healthy file in this situation is how a non-problem turns into a real one.
Wrong provider: Jet 4.0 cannot read .accdb
If Access opens the file but Excel, Power Query, a Python script, a .NET service, VB6 or classic ASP reports the error, the file is almost certainly fine and the connection is wrong. The Jet 4.0 OLE DB provider understands only the older .mdb format. The .accdb format needs the ACE provider or the Access ODBC driver, which means the Microsoft Access Database Engine must be installed on that machine, in the same bitness (32-bit or 64-bit) as the program calling it.
Real damage: an interrupted write
Access writes changes directly into the file. If a write is cut off partway through, for example by a dropped network connection, a laptop going to sleep, a power cut or a VPN timeout, the structure describing where objects live can be left inconsistent. Access reads the header, finds something it cannot interpret, and refuses to open rather than risk making it worse. In these cases the records themselves are usually still in the file.
A 15 minute safe diagnosis
This sequence only reads the file and only touches copies. None of it can make the situation worse.
Stop everyone from opening the file. Every attempt can write to it, and Access also creates a lock file next to the database each time it is opened.
Copy the file to a local drive and label it clearly, for example Copy_of_Sales_2026-10-07.accdb. Work only on copies from now on.
Find your most recent backup, even if it is days old, and copy it somewhere safe as your fallback.
Try the copy in the newest version of Access you can reach, on any computer. If it opens, this was a version problem. Save it forward and you are done.
If the error appears in Excel, Power Query or an application rather than in Access, check the provider or driver in the connection string (examples below).
If it fails everywhere, check the file size and read the header bytes with the script below. This tells you whether you are dealing with a bad copy, a legacy format or real damage.
Write down what was happening when it broke: who was in the file, whether they were on Wi-Fi or VPN, whether a machine crashed or a sync tool was running. This narrows the diagnosis considerably.
Read the header of a copy (PowerShell, read-only)
A healthy Access file begins with the bytes 00 01 00 00, followed by the text Standard ACE DB for .accdb or Standard Jet DB for .mdb. The byte at offset 0x14 shows the format generation. This script reads 32 bytes and changes nothing.
PowerShell
# Read-only check of an Access file's header. Run it on a COPY.
$path = 'C:\Recovery\Copy_of_Sales.accdb'
$fs = [System.IO.File]::Open($path, 'Open', 'Read', 'ReadWrite')
$buf = New-Object byte[] 32
[void]$fs.Read($buf, 0, 32)
$fs.Close()
"Size (bytes) : " + (Get-Item $path).Length
"First 4 bytes : " + (($buf[0..3] | ForEach-Object { '{0:X2}' -f $_ }) -join ' ')
"Engine tag : " + [System.Text.Encoding]::ASCII.GetString($buf, 4, 15)
"Version byte : 0x{0:X2}" -f $buf[0x14]
# A healthy file starts with 00 01 00 00, then the text
# 'Standard ACE DB' (.accdb) or 'Standard Jet DB' (.mdb).| What the check shows | What it means | What to do |
|---|---|---|
| Size is 0 bytes or only a few KB | The copy is empty or truncated. | Re-copy from the source. Check OneDrive, Dropbox or server version history. |
| Tag reads Standard ACE DB, version byte 02 to 05 | A valid .accdb. The byte is the format generation (2007, 2010, 2013, 2016 and later). | If your Access is older than the file, this is a version problem. If your Access is current, suspect damage (cause 6). |
| Tag reads Standard Jet DB, version byte 01 | A Jet 4 .mdb (Access 2000 to 2003 era). | Opens in current Access. If it will not, suspect damage (cause 6). |
| Tag reads Standard Jet DB, version byte 00 | An Access 97 era .mdb. | Needs conversion through an older Access version (cause 3). |
| No tag, first bytes all 00 | The header has been zeroed or the file is empty on disk. | Not a version problem. Go to backups and snapshots, then specialist recovery. |
| No tag, content looks random | The file may be encrypted, or it may not be an Access file at all. | If ransomware is possible, disconnect the machine from the network before anything else. |
Fixes by cause
If it is a version mismatch
Open the file in the newest Access available, then save it in a format your other users can read. If the file contains features older versions do not support, the cleaner long-term answer is to bring every user to the same Access version, or to give each desktop the same Access runtime. Do not run Compact and Repair as a test; it changes the file and the file is not damaged.
If an application or script is raising the error
Change the provider or driver. The most common fix is replacing Jet 4.0 with the ACE provider. Install the Microsoft Access Database Engine at the same bitness as the application, since a 64-bit app cannot load a 32-bit provider and vice versa.
Connection strings
' WRONG for .accdb files (Jet cannot read the ACE format):
Provider=Microsoft.Jet.OLEDB.4.0;Data Source=C:\Data\Sales.accdb;
' RIGHT (OLE DB). Needs the Access Database Engine installed:
Provider=Microsoft.ACE.OLEDB.12.0;Data Source=C:\Data\Sales.accdb;
' RIGHT (ODBC), for example from Python with pyodbc:
Driver={Microsoft Access Driver (*.mdb, *.accdb)};DBQ=C:\Data\Sales.accdb;If it is an Access 97 or other very old .mdb
Current Access builds can refuse the oldest formats. The usual route is converting the file through an older Access version that still opens it, then saving it forward. If you no longer have that version, this is a quick, low-risk job for a specialist, and one of the easiest cases to resolve completely.
If the file is a bad copy
Compare the file size to the source. A zero-byte or unusually small file is a failed copy, download or sync. Go back to the original location, then check version history in OneDrive or Dropbox, Windows Previous Versions on the folder, and server or NAS snapshots. Sync tools can also create conflict copies of an open database, so check for files with a computer name or the word conflict in the file name.
If the structure is damaged
On a copy, you can try Open and Repair from the Open dialog (use the arrow beside the Open button), and then import tables into a new blank database through External Data. These work only when Access can open the file at least partly. If they fail, or you have already tried them, stop. The remaining options are a backup, snapshot or specialist recovery, and each further rewrite reduces what can be recovered.
If the header is gone or the file is encrypted
A zeroed header or a file that looks like random data is not a version problem. If ransomware is possible, disconnect the computer from the network first. Then look for backups, shadow copies and snapshots before anything else. Do not pay for or run decryption tools of unknown origin against your only copy.
What not to do
Do not run Compact and Repair on your only copy. It rewrites the file in place and can fail partway through.
Do not run a series of third-party repair tools hoping one works. Most save output over the source, and each pass reduces what a specialist can recover.
Do not delete the damaged original once you have a partial recovery. Later passes often get more out of it.
Do not keep working in a recovered copy on the same network share that broke it. You will be back here.
Do not rename the extension to try to force it open. A .accdb renamed to .mdb is still an .accdb inside and will fail the same way.
VBA for inspecting and salvaging a copy
If you have a newer Access install available, these two procedures help you see how much of a damaged copy is readable. Put them in a standard module of a new blank database (not in the damaged file), and run them against a copy. The first reports the exact error and a row count per table. The second imports every readable table. They only help when the engine can open the file far enough to list its tables; if it cannot, the problem is at the header level and needs specialist recovery.
VBA: probe a damaged copy (read-only)
Option Compare Database
Option Explicit
' Run from a NEW blank database in the newest Access you have.
' Opens a COPY of the damaged file read-only and reports what DAO can see.
Public Sub ProbeDamagedFile(ByVal copyPath As String)
Dim db As DAO.Database
Dim td As DAO.TableDef
Dim n As Long
On Error GoTo OpenFailed
Set db = DBEngine.OpenDatabase(copyPath, False, True) ' read-only
On Error GoTo 0
Debug.Print "Opened OK. Tables found:"
For Each td In db.TableDefs
If (td.Attributes And dbSystemObject) = 0 And Left$(td.Name, 1) <> "~" Then
n = SafeRowCount(db, td.Name)
Debug.Print " " & td.Name & ": " & IIf(n >= 0, n & " rows", "UNREADABLE")
End If
Next td
db.Close
Exit Sub
OpenFailed:
' Error 3343 = Unrecognized database format
Debug.Print "Open failed. Error " & Err.Number & ": " & Err.Description
End Sub
Private Function SafeRowCount(db As DAO.Database, ByVal tblName As String) As Long
Dim rs As DAO.Recordset
On Error GoTo Bad
Set rs = db.OpenRecordset("SELECT Count(*) AS N FROM [" & tblName & "]", dbOpenSnapshot)
SafeRowCount = rs!N
rs.Close
Exit Function
Bad:
SafeRowCount = -1
End FunctionVBA: salvage readable tables from the copy
' Pulls every readable local table from the damaged COPY into this database.
' Only useful when the file opens far enough for DAO to list its tables.
Public Sub SalvageTables(ByVal copyPath As String)
Dim db As DAO.Database
Dim td As DAO.TableDef
Dim okCount As Long, failCount As Long
Set db = DBEngine.OpenDatabase(copyPath, False, True)
For Each td In db.TableDefs
If (td.Attributes And dbSystemObject) = 0 _
And Left$(td.Name, 1) <> "~" _
And Len(td.Connect) = 0 Then
On Error Resume Next
DoCmd.TransferDatabase acImport, "Microsoft Access", copyPath, _
acTable, td.Name, "Salvaged_" & td.Name
If Err.Number = 0 Then
okCount = okCount + 1
Else
failCount = failCount + 1
Debug.Print "FAILED: " & td.Name & " (" & Err.Number & ") " & Err.Description
Err.Clear
End If
On Error GoTo 0
End If
Next td
db.Close
Debug.Print "Imported " & okCount & " tables, " & failCount & " failed."
End SubUsage from the Immediate window: ProbeDamagedFile "C:\Recovery\Copy_of_Sales.accdb". A table that returns UNREADABLE is where the damage sits. Keep that list, because it tells a specialist exactly where to start.
How we recover the file
Our recovery sequence
Diagnosis before intervention, always on copies.
2. Extract at table level
Rather than repairing in place, we read the tables directly out of the damaged file so the data is secured before any rebuilding starts.
3. Rebuild the structure
Tables, relationships, queries, forms, reports and VBA are rebuilt into a clean database, so you are not left with a fragile file that fails again next week.
4. Verify against something real
We reconcile record counts and check figures your team recognises, such as last month's totals, open orders and current stock, so you know exactly what came back.
5. Fix the cause
A recovered file on the same setup will corrupt again. We split the database properly, move front ends to each desktop, and tell you plainly if the data belongs on SQL Server.
Work is performed on backup copies only - secure handling, nothing shared with third parties.
When the data is recoverable, and when it is not
If the damage sits in the objects around the data, such as the catalogue, forms, queries or the VBA project, the records normally come back in full. If it landed inside the data pages themselves, some rows in the affected tables can be unreadable, and honest recovery means telling you which tables and roughly how many rows instead of quietly delivering a file with gaps. A zeroed header or an encrypted file with no backup is the hardest case and we will say so up front. The single biggest factor is not how severe the original corruption was; it is how many times the file has been rewritten since. An untouched original is the best thing you can give us.
What it costs
Fixed-scope project estimates based on the business value we deliver. Projects typically start at $1,200 - smaller fixes can be less, larger systems more.
The assessment is free, and you get the figure in writing before any billable work starts. If the honest answer is that your file only needs opening in a newer version of Access, or a corrected connection string, we will tell you that and there is nothing to pay. For the wider picture on pricing, see Access database repair or talk to a Microsoft Access consultant. If Compact and Repair is the step that is failing for you, read Compact and Repair not working.
Stopping it happening again
Nearly every damaged file we recover comes from the same setup: one database file on a share, opened directly by several people, at least one of them over Wi-Fi or VPN. The database should be split, with a front end copied to each desktop and only the data on the server. If more than a handful of people work in it at once, or anyone connects remotely, the data belongs in SQL Server with Access kept as the screens - see Access to SQL Server migration. For why remote connections cause this, read Access corruption over LAN, Wi-Fi and VPN. If the database is already in daily use and you want it kept healthy, that is what Access support is for.
Split the database: a front end on each desktop, a back end on the server.
Standardise the Access version across users, or deploy the same runtime to everyone.
Never let a sync tool (OneDrive, Dropbox) copy a database while it is open.
Keep dated backups of the back end and test a restore, not just the backup job.
Keep remote users off direct file-share connections. Use a remote desktop session or SQL Server instead.
FAQ
Frequently Asked Questions
Find answers to common questions about our services
It means the Access database engine opened the file, read its header and could not interpret what it found. Access developers also see it as run-time error 3343. Outside the US it is often spelled 'unrecognised database format'. The cause is either a version or provider mismatch, where the file is healthy but the software reading it is the wrong one, or real damage to the file's internal structure.
Yes. Error 3343 is the DAO and Jet/ACE error number behind the message 'Unrecognized database format' followed by the file path. You may see the number in VBA error handlers, Access error dialogs, and in apps that use the Access engine, such as Excel, Power Query, or custom .NET and Python tools.
Try the file on a computer with the newest Access you can find. If it opens there, it was a version problem and the file is healthy. If it only fails in code or in Excel, the connection provider is wrong. If it fails everywhere, read the first bytes of a copy: a valid file starts with 00 01 00 00 and then the text 'Standard ACE DB' or 'Standard Jet DB'. A missing tag or a zero-byte file is damage or a bad copy, not a version issue.
Because that app is using a different data engine than Access does. The classic cause is a connection string using the Microsoft.Jet.OLEDB.4.0 provider against an .accdb file. Jet only understands the older .mdb format. Switching to the ACE provider (Microsoft.ACE.OLEDB.12.0) or the Microsoft Access ODBC driver fixes it, provided the Access Database Engine is installed and its bitness matches the calling app.
In most cases the records are still physically in the file. Access refuses to open it because the structure describing where objects live is damaged, not because the rows were deleted. The exception is a zeroed header, an empty file or encryption, where the data may be unrecoverable without a backup or snapshot. A specialist can tell you which situation you are in before you commit to anything.
Not on your only copy. Compact and Repair rewrites the file in place, and if it fails partway you can end up with less than you started with. Copy the file first and try Open and Repair or Compact and Repair on the copy. It also will not help when the problem is a version mismatch, because the file is not damaged.
Often yes, but the odds drop each time a tool rewrites the file. Many repair utilities save their output over the source. If you have an untouched copy or an older backup, send that as well, even if it is a few days old. A slightly stale file in good condition is usually worth more than a current file that several tools have rewritten.
Often not directly. Current Access builds have dropped support for the oldest formats, so a very old .mdb can trigger the unrecognized format error even though the file is fine. The usual route is to convert it through an older Access version that can still open it, then save it forward to a current format. If you do not have that version available, a specialist can do the conversion for you.
The most common real-corruption cause we see is a write interrupted by the network: a shared database on a file server or NAS, opened over Wi-Fi or VPN, where a laptop dropped its connection mid-transaction. Others are an unsplit database shared by several people, a workstation losing power with the file open, a front end left on a network share, and sync tools copying a file while it is open.
We quote a fixed price for a defined piece of work rather than billing hourly. Fixed-scope project estimates based on the business value we deliver. Projects typically start at $1,200 - smaller fixes can be less, larger systems more. The first step is a free assessment: we tell you what is recoverable before you commit to anything. Projects typically start at $1,200, and urgent cases are usually looked at the same business day. If the honest answer is that your file only needs a newer version of Access, we say so and there is nothing to pay.
Need this file open again?
Send us the details and your most recent backup. We will tell you what is recoverable before you commit to anything.
1
15-min audit
→
2
Fixed-scope quote
→
3
Deliver outcome
15+Years Experience
FixedScope Quotes
2011Established
Prefer to talk? Call us at +1 385 386 3860