How to Test Your Access Database After Converting .mdb to .accdb

You converted the file. The .accdb exists. But is it actually working? A migration that looks complete can still be silently broken — forms that open but show wrong data, queries that run but return wrong counts, VBA that compiles but fails at runtime. If you haven't yet started the conversion process, our complete guide to Access database migration covers the full .mdb to .accdb workflow. This checklist walks through every layer of your database so you know before your users find out.

Why Testing Matters More Than You Think

The Jet 4.0 engine (.mdb) and ACE engine (.accdb) behave identically for most operations — but not all. Known differences include:

• Reserved word conflicts — words like Date, Name, Status work fine in Jet, but ACE treats some as reserved. Queries and forms referencing these fields without brackets will error.
• VBA PtrSafe requirement — any API declarations using Declare Function need the PtrSafe keyword in 64-bit Access. Without it, the entire module fails to compile.
• DAO references — .accdb files use ACE DAO. If your VBA hardcodes the Jet 4.0 DAO reference, it will break.
• Linked table connection strings — .accdb stores these differently. External links to Excel, SQL Server, or text files may need to be refreshed.

None of these cause the conversion itself to fail. They surface only when you actually use the database.

Before You Start: Protect Your Original

Never test against the original .mdb. Keep it read-only until you're confident the .accdb works in production.

1. Copy the .accdb to a test environment (local machine or isolated network share)
2. Keep the .mdb accessible for comparison queries
3. Document every issue you find — you may need to re-migrate specific tables or objects

The Complete Post-Migration Testing Checklist

1. Structural Integrity

• Open the .accdb in Access 2016 or later — no startup errors or yellow warning bars
• Run Database Tools > Compact and Repair — completes without errors
• No "unrecognized database format" errors on open

2. Data Integrity

• Run SELECT COUNT(*) FROM [TableName] on every table — match row counts to .mdb
• For financial or numeric tables, compare SUM() totals on key fields
• Check for truncated text — Memo fields (now Long Text) behave differently at 255+ characters
• Verify Null values are preserved (not converted to empty strings)
• Check date fields — verify year, month, day accuracy on sample records

3. Queries

• Open each query in Design View — no red "?" field name errors
• Run every select query — correct row counts and data
• Run action queries (append, update, delete) against test data
• Check queries using reserved words in field names — wrap in brackets: [Status], [Date], [Name]
• Union queries and pass-through queries: verify syntax still valid

4. Forms

• Open every form — no "object is closed or doesn't exist" errors
• Navigate records in each form — correct data, field bindings intact
• Test all subforms — parent/child record links working
• Test combo boxes and list boxes — row sources loading correctly
• Test calculated controls — expressions returning correct values
• Test all command buttons — events firing as expected

5. Reports

• Open every report in Print Preview — no missing fields or #Error values
• Check grouping and sorting — records grouped correctly after migration
• Verify calculated fields in report footers (totals, averages) match expected values
• Export one report to PDF — formatting intact

6. Macros and VBA

• Run each macro from the Navigation Pane — no "Action Failed" dialogs
• Open VBA editor (Alt+F11) — no red error highlighting in any module
• Debug > Compile — compiles without errors
• Tools > References — no broken references (shown as "MISSING:")
• Check Declare Function statements — add PtrSafe for 64-bit compatibility
• Test any VBA using DAO or ADO recordsets — confirm they open correctly

7. Linked Tables

• Open Linked Table Manager — refresh all links
• Verify links to external Excel workbooks — paths still valid
• Verify links to SQL Server or ODBC sources — connection strings intact
• Open each linked table — data loads without error

8. End-to-End Workflow Test

• Walk through your most critical daily workflow from start to finish
• Enter new test records — they save without errors
• Run the reports your team depends on
• Export data to Excel or CSV — output matches expectations
• Test with actual user accounts that will access the database

Common Failures and Fixes

Symptom	Likely Cause	Fix
Form opens but shows no data	Record source query uses a reserved word without brackets	Bracket field names in the query: [Date], [Status], [Name]
VBA fails to compile	Missing PtrSafe on API declarations	Add PtrSafe after Declare in all API function declarations
Linked table shows "MISSING:"	File path changed or drive letter different	Open Linked Table Manager and repoint to the correct file location
Report shows #Error in calculated field	Underlying query field name conflict	Fix reserved word issue in the query; rebind the report control
Row counts don't match	Data truncated during conversion	Run comparison query between .mdb and .accdb; identify affected table

What Comes After a Successful Migration

Once your .accdb is tested and stable, you have a decision: keep running Access, or modernize the application. Access is reliable desktop software — but it wasn't designed for cloud access, mobile users, or teams larger than about 10 concurrent users.

If your Access database has been the backbone of a business process for years, it might be time to consider what a modern web application version would look like. AccessLeap generates a deployable web app directly from your validated .accdb — reading only the structural schema, never your data.

Related Resources

• ActiveX Controls in Access: What Breaks After Migration and How to Fix It
• How to Verify Data Integrity After Access Database Migration
• 5 Signs Your Access Database Needs More Than Migration
• Access Database to SQL Server Migration: Complete Guide

← Back to all posts