You've just moved your Access database to a new server, a new PC, or a new file share. Everything looked fine during the move. Then someone opens the database and gets this:
Could not find file '\\oldserver\data\customers.accdb'.
Or this:
The Microsoft Access database engine cannot find the input table or query 'tblOrders'.
Your linked tables are broken. Every query, every form, every report that touches external data is now dead. Here's exactly why this happens — and the exact steps to fix it.
Access uses a split database architecture. The "front end" is an .accdb file containing your forms, queries, reports, and VBA code. The "back end" is a separate file (or SQL Server database) containing the actual data tables.
The front end stores the connection to the back end as a hardcoded path. When you built the system, that path pointed to \\oldserver\share\data.accdb. When you move the back end to a new location, Access still points to the old path — which no longer exists.
Three types of linked tables can break:
C:\Users\jsmith\Documents\data.accdbEach type breaks differently and requires a different fix.
In Access, go to External Data > Linked Table Manager. You'll see a list of all linked tables and their current connection paths.
Tables with a red or broken icon are the problem. Note the old path — you'll need to know where the data has moved to.
Access will relink all selected tables to the new file. If you have multiple back-end files, repeat for each one.
ODBC-linked tables break when the DSN changes (server rename, database move, credentials update). You have two options:
Option A — Update the DSN: Open Windows' ODBC Data Source Administrator (search for "ODBC" in Control Panel), find the DSN your database uses, and update the server name, database name, or credentials to match the new environment.
Option B — Relink with a new connection string: In the Linked Table Manager, select the ODBC tables and click Relink. Choose your ODBC source from the list (or create a new one). This stores a new connection string directly in the table link.
LegacyLeaps scans your .accdb and reports every linked table path — file-based, ODBC, and SharePoint — before you start the migration.
Scan Your Database FreeSharePoint links break when the site URL changes (domain rename, site collection move, tenant migration). In the Linked Table Manager, select the broken SharePoint links and provide the new site URL. If the list name changed, you'll need to relink manually from External Data > More > SharePoint List.
Once you've fixed the links, here's how to keep them from breaking next time:
Drive letters are machine-specific. S:\data\backend.accdb only works on machines where the S: drive is mapped. \\fileserver\shared\data\backend.accdb works from any machine on the network. Always link using UNC paths.
Some developers put the front end and back end in the same folder. When you move them together, the relative path stays valid. This doesn't work across network shares, but it simplifies single-machine deployments.
A common pattern is an AutoExec macro or VBA startup function that checks whether the linked table paths are still valid. If not, it prompts the user to browse to the new location. Here's a basic VBA version:
Function RelinkTables(sNewPath As String) As Boolean
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
' Only relink Access file links
If Left(tdf.Connect, 10) = ";DATABASE=" Then
tdf.Connect = ";DATABASE=" & sNewPath
tdf.RefreshLink
End If
End If
Next tdf
RelinkTables = True
End Function
Call this from your startup form with the correct path, and your users never see a broken table error again.
If you're still running an older .mdb format database, linked table problems are compounded by the older Jet database engine limitations. Converting from .mdb to .accdb with LegacyLeaps gives you a cleaner starting point — the conversion preserves all linked table definitions and VBA code while modernizing the engine.
After the conversion, use the Linked Table Manager to update any paths that changed during the migration. For a comprehensive walkthrough of this process, see our guide on re-linking linked tables after migration.
Some organizations fix their linked table issues every few years when a server moves — and then spend time wondering if it's finally time to get off Access entirely. If that sounds familiar, the question worth asking is whether the architecture that requires manual relinking is the architecture you want to maintain long-term.
AccessLeap uses AI to generate a modern web application from your .accdb database — tables, forms, business logic, and all. Your data stays on your machine during generation. No linked table problems. No more Access dependency.
Learn About AccessLeap| Link Type | Why It Breaks | Fix |
|---|---|---|
| .accdb / .mdb linked tables | Hardcoded file path changed | Linked Table Manager > Relink with new path |
| ODBC / SQL Server | DSN changed or server moved | Update DSN in ODBC Data Source Admin, or relink with new connection string |
| SharePoint lists | Site URL changed | Linked Table Manager > Provide new site URL |
Broken linked tables are a migration pain, not a sign your database is broken. Follow these steps, and you'll have everything working in under an hour — even for large systems with dozens of linked tables.
LegacyLeaps scans your .mdb or .accdb and shows you every linked table, VBA reference, and compatibility issue before you start. Free scan, no commitment.
Download Free ScannerPractical fixes for legacy Excel and Access problems. No spam.