You migrated your Access database from .mdb to .accdb. The conversion went smoothly — except now half your forms show errors and nothing pulls data correctly. The culprit is almost always the same thing: linked tables pointing to paths that no longer exist.
Linked tables are one of the most powerful features in Access and one of the most fragile parts of any migration. Here's what's happening, why it breaks, and exactly how to fix it — manually and at scale.
In Access, a linked table isn't a copy of your data — it's a pointer. The table definition lives in your front-end database (.accdb), but the actual rows live in a separate file: another database, a SQL Server table, an Excel spreadsheet, or an ODBC source.
That pointer is stored as a connection string. For a linked .mdb or .accdb file, it looks something like this:
;DATABASE=C:\Data\Operations\inventory.mdbWhen you migrate, several things can invalidate that string:
inventory.mdb to inventory.accdb in a new folder..mdb but the file is now .accdb.\\server01\data is now \\fileserver\shared.Any of these will cause Access to display a broken chain icon next to the table, and any form or query built on that table will fail with a "Could not find file" or "ODBC connection failed" error.
Before you start fixing, know what you're dealing with. Open your migrated database and go to:
Database Tools > Linked Table Manager
In Access 2016 and later, the Linked Table Manager shows every linked table with its current connection string. Broken links are flagged immediately. In older versions, you may need to click "Refresh" to see which ones fail.
You can also check programmatically. Open the VBA editor (Alt+F11) and run this:
Sub CheckLinkedTables()
Dim db As DAO.Database
Dim tdf As DAO.TableDef
Set db = CurrentDb
For Each tdf In db.TableDefs
If Len(tdf.Connect) > 0 Then
Debug.Print tdf.Name & " | " & tdf.Connect
End If
Next tdf
End SubThis prints every linked table name and its full connection string to the Immediate window. Review the paths — any that reference old file names, old directories, or machine-specific DSNs need to be updated.
For small databases with a handful of linked tables, the Linked Table Manager is fast enough:
.accdb file and select itAccess will update all selected links to point to the new file. If you have tables linking to multiple source databases, repeat the process for each source.
Tip: If the Linked Table Manager is grayed out, you're probably in a split database where the front-end is read-only. Make a writable copy of the front-end .accdb before re-linking.
LegacyLeaps handles linked table re-mapping automatically — no manual GUI work, no missed connections.
Try the Free ScanIf you have dozens of linked tables or you're migrating multiple front-end databases that all link to the same back-end, VBA is the right tool. Here's a reusable procedure:
Sub RelinkTables(oldPath As String, newPath As String)
Dim db As DAO.Database
Dim tdf As DAO.TableDef
Set db = CurrentDb
For Each tdf In db.TableDefs
If InStr(tdf.Connect, oldPath) > 0 Then
' Update the connection string
tdf.Connect = Replace(tdf.Connect, oldPath, newPath)
' Refresh the link
tdf.RefreshLink
Debug.Print "Relinked: " & tdf.Name
End If
Next tdf
MsgBox "Done. Check the Immediate window for details."
End SubCall it with:
RelinkTables "C:\Old\inventory.mdb", "C:\New\inventory.accdb"This replaces the old path in every connection string that contains it, then calls RefreshLink to test the connection. If a link fails to refresh, you'll get a runtime error on that specific table — which tells you exactly what still needs attention.
When you convert the back-end from .mdb to .accdb, the connection string format changes slightly. An .mdb link uses the Jet provider:
;DATABASE=C:\Data\inventory.mdbAn .accdb link uses ACE:
;DATABASE=C:\Data\inventory.accdbThe Replace call above handles both the path and the extension change if you include the full filename in your oldPath argument. If your old and new files have different names beyond the extension, adjust accordingly.
If your linked tables connect to SQL Server, Oracle, or another ODBC source via a DSN, migration is more complex. The DSN must exist on every machine that opens the database, and machine-specific (User) DSNs don't transfer automatically.
The safest approach is to switch from DSN-based connections to DSN-less connections, which embed the full connection string in the TableDef:
tdf.Connect = "ODBC;DRIVER={SQL Server};" & _
"SERVER=myserver;DATABASE=mydb;" & _
"Trusted_Connection=Yes;"
tdf.RefreshLinkDSN-less connections work on any machine with the appropriate ODBC driver installed, without requiring IT to configure a DSN on each workstation. This is almost always the right architecture for shared databases.
Don't assume a successful RefreshLink means everything works. Run a validation pass:
If you see a field name error after re-linking, it usually means the field structure in the new back-end differs from what the link expects — a schema migration issue, not a linking issue. Data integrity verification after migration covers how to audit these differences systematically.
Most well-designed Access databases use a split architecture: a back-end .mdb or .accdb that holds the tables, and a front-end .accdb that holds the queries, forms, reports, and VBA code. When you migrate, you typically need to:
The most common mistake is trying to convert both at once through Access's built-in "Convert to .accdb" tool, which converts the front-end but leaves the back-end as .mdb — and updates the links to point to the unconverted file. You end up with an .accdb front-end pointing at an .mdb back-end, which works but misses the performance and security benefits of a fully converted stack.
Download LegacyLeaps and scan your files for free. See exactly what needs to be converted before you spend a penny.
Download Free ScannerLinked tables store the file path or DSN connection string to the source database. When you migrate or move files, those paths often change, so the link points to a location that no longer exists or is now a different format.
Use the Linked Table Manager (Database Tools > Linked Table Manager), select all broken links, check "Always prompt for a new location", and browse to the new database file location. For multiple databases or automation, update the TableDef.Connect property via VBA and call RefreshLink.
Yes. VBA code can loop through all TableDef objects with a Connect property, update the connection string to the new path, and call RefreshLink. LegacyLeaps handles this automatically during migration, updating all linked table references as part of the conversion.
An imported table copies the data into your database — changes in Access don't affect the source. A linked table is a live pointer — changes in Access write through to the source file. Most multi-user Access databases use linked tables so all users see the same shared data.
Practical fixes for legacy Excel and Access problems. No spam.