If you've worked with Microsoft Access for more than a decade, you've lived through the format change. Before 2007, every Access database ended in .mdb. Then Access 2007 arrived and quietly introduced a new extension: .accdb. Many users just kept opening their old files and didn't think much about it — until they couldn't anymore.
This post explains what actually changed between .mdb and .accdb, why Microsoft made the switch, and what's at stake if you're still running .mdb databases in a modern Windows environment.
The .mdb format is powered by the Jet 4.0 database engine, a technology Microsoft introduced in the late 1990s. The .accdb format uses the ACE (Access Connectivity Engine), which Microsoft introduced with Office 2007 as Jet's successor.
Microsoft stopped actively developing Jet around 2005. It still ships with Windows as a compatibility layer, but it receives no new features and minimal security patches. ACE is the living engine — it's what gets updated when you update Office.
| Feature | .mdb (Jet 4.0) | .accdb (ACE) |
|---|---|---|
| Introduced | Access 97 / 2000 | Access 2007 |
| Max file size | 2 GB (hard ceiling) | 2 GB (with better compression) |
| Database engine | Jet 4.0 | ACE 12.0+ |
| Multi-valued fields | Not supported | Supported |
| Attachment fields | Not supported | Supported |
| Calculated fields | Not supported | Supported |
| Encryption | Weak (RC4-based) | Strong (AES 128-bit) |
| User-level security | Supported (workgroup files) | Removed |
| SharePoint integration | Limited | Full |
| Macro language | Legacy macros only | Embedded macros + VBA |
| Active development | No (frozen at Jet 4.0) | Yes (updated with Office) |
Here's what creates confusion: Jet 4.0 still ships with Windows. You can still open most .mdb files today. Microsoft hasn't yanked out the engine — they've just stopped improving it.
The problems show up at the edges:
So Jet isn't dead today. But it's on borrowed time, and every Windows update is a potential breaking change for .mdb databases.
In .mdb, you couldn't store multiple values in a single field without junction tables. .accdb supports multi-valued lookup fields natively — useful for tagging records, assigning multiple categories, or tracking many-to-many relationships without extra schema.
.accdb introduced the Attachment data type, which lets you store files directly in a database record — images, PDFs, documents. The engine handles compression automatically. No equivalent exists in .mdb.
The "password protection" in .mdb was notoriously weak. The RC4-based encryption could be broken with freely available tools in seconds. .accdb uses AES encryption (AES-256 in Access 2010+), which is actually secure. If you're storing sensitive data in a legacy .mdb, this alone is reason to migrate.
This one is a double-edged change. .mdb had a workgroup security model — you could create .mdw files that defined user accounts and permissions at the database level. .accdb dropped this entirely, relying instead on Windows/SharePoint permissions.
If your .mdb database relied on workgroup security (common in small businesses that never set up proper Windows AD), migrating to .accdb requires replacing that security model. It's a real migration task, not just a file rename.
Here's the good news: the core building blocks of an Access database — tables, queries, forms, reports, and standard VBA code — migrate cleanly from .mdb to .accdb in almost all cases.
Your customer records, transaction history, inventory data, and report layouts come through intact. The migration challenge is in the plumbing: VBA code that references Jet-specific behaviors, ActiveX controls on forms, ODBC connection strings pointing to Jet drivers, and any workgroup security setup.
LegacyLeaps scans your Access database and shows exactly what needs attention before you migrate — VBA code, ActiveX controls, security settings, and Jet SQL syntax issues.
Run a Free ScanMost VBA code works the same across both formats. The exceptions are specific to Jet:
DBEngine.CreateWorkspace with dbUseJet, or references to workgroup security objects like User and GroupMakeReplica and related methods; ACE doesn'tA proper migration audit flags each of these. They're fixable — but you need to know they're there before you convert. For a deeper look at what to check, see our guide on VBA changes during migration.
Access forms built in the late 1990s through mid-2000s often used ActiveX controls — third-party calendar pickers, grid controls, chart components. These were registered COM objects that Access embedded in forms.
ActiveX controls are a significant problem in modern Windows because:
This isn't an .mdb vs .accdb problem specifically — it affects both formats in modern environments. But if you're migrating anyway, it's the right time to audit and replace these controls with native Access controls or modern alternatives.
The SQL dialect differences are minor but real. Key changes in ACE:
DISTINCTROW is still supported in ACE but rarely needed — consider using DISTINCT for clarity*= and =* outer join syntax isn't supported — use LEFT JOIN / RIGHT JOINIIF() edge cases behave differentlyFor most databases, these SQL differences don't surface. For complex query-heavy databases, a SQL audit is worth doing before conversion.
If your .mdb database is read-only archival data that nobody touches anymore, you can probably leave it. But if it's in active use — people open it daily, run reports from it, or connect applications to it — you should plan a migration.
The case for migrating now:
The case for waiting: migration takes real work, especially if your database has VBA code, ActiveX controls, or workgroup security. "It works today" is a valid reason to plan carefully rather than rush.
The wrong approach is to ignore it until something breaks.
LegacyLeaps's Access migration runs in three phases:
Your original .mdb is never modified. LegacyLeaps creates the .accdb alongside it, so you can compare and roll back if anything looks off.
.mdb uses the older Jet 4.0 database engine and is limited to 2GB. .accdb uses the newer ACE engine, adds multi-valued fields, Attachment fields, proper AES encryption, and SharePoint integration. .accdb was introduced in Access 2007 and is the current standard format.
Yes, with caveats. Access 2019 and 2021 open .mdb files in a compatibility mode where new features are unavailable. Some .mdb files fail to open after Windows 11 updates. Microsoft has not committed to maintaining .mdb support indefinitely.
Yes, with the right tool and a proper audit first. The main risks are VBA code that relies on Jet-specific objects, ActiveX form controls, and workgroup security setups. A migration tool that audits before converting eliminates surprises.
Microsoft introduced .accdb to address Jet 4.0's limitations: no multi-valued fields, weak encryption, no support for modern Windows authentication, and a 2GB ceiling with no compression. Jet also had no 64-bit driver path, which became untenable as Windows moved to 64-bit.
Standard VBA module code survives the conversion intact. Code that references Jet-specific DAO objects, uses workgroup security, or calls outdated ISAM drivers needs updating. LegacyLeaps audits and rewrites affected code as part of the migration.
Coming Soon
AI-powered code generation from .accdb files. Your data never leaves your machine.
Download LegacyLeaps and scan your .mdb file for free. Get a full report of what needs attention before you convert a single record.
Download Free ScannerPractical fixes for legacy Excel and Access problems. No spam.