Fix Access Error 3167: Record Is Deleted (Linked Tables)

One of the more confusing errors I get called about is 3167. A user opens a form or scrolls through a report, and Access throws up "Record is deleted." Nobody deleted anything. The data was there five minutes ago. And it almost always happens on a database that uses linked tables.

If that sounds like your situation, this post walks through what the error actually means, why it shows up specifically with linked tables, and the practical steps to clear it. I'll keep it plain, because most of the people who email me about this run the business rather than build the database.

What error 3167 actually means

In Access terms, 3167 means your front-end is pointing at a record that no longer exists where the data is really stored. Access is reading from a link, not the real data. When the two fall out of sync, Access tells you the record was deleted even if, from your point of view, nothing was.

This is different from most corruption messages. The record you're looking at may be perfectly intact in the back-end file. The problem is the connection between where you're looking and where the data lives.

Why linked tables are involved

Nearly every well-built Access system is split into two files: a front-end (forms, reports, queries) on each user's PC, and a back-end (just the tables) on a shared folder or server. The front-end reaches the back-end through linked tables. If you're not sure what that split looks like, the short version is the data and the interface live in separate files connected by those links.

Error 3167 shows up here because there are now two moving parts that can get out of step:

• The back-end file the links point to may have changed, moved, or been restored from an older copy.
• The index that Access uses to find records can become stale, so it tries to fetch a row that has shifted or gone.
• Another user may have deleted the record while you still had it loaded on screen.

The most common causes I see

In my experience, Access error 3167 on linked tables comes down to a handful of culprits. Knowing which one you're dealing with saves a lot of guessing.

1. A real multi-user deletion. Two people are in the same database. One deletes a customer or an order; the other is still looking at that record on an open form. When the second person touches it, Access reports it's gone. This is the most harmless version and usually clears with a refresh.
2. A corrupted index in the back-end. The record exists, but the index that locates it is damaged. Access follows a broken pointer and concludes the record was deleted. This one does not clear with a refresh.
3. A stale or broken table link. The back-end was moved, renamed, or swapped for a restored backup with a different internal structure. The links still "work" enough to open but return phantom records.
4. Early-stage corruption. 3167 is sometimes the first warning sign before bigger problems appear. If you're also seeing the database behave oddly in other ways, treat it seriously.

If 3167 keeps returning after a refresh, stop editing data in that database and make a copy of the back-end file before you do anything else. Working in a corrupted file can turn a recoverable problem into an unrecoverable one.

How to fix it, step by step

Here's the order I work through when I'm troubleshooting this. Start simple and only move to the heavier steps if the error persists.

1. Refresh and retry. Press Shift+F9 on the form, or close and reopen it. If a colleague simply deleted the record while you had it open, this resolves it and nothing is wrong with the database.
2. Have everyone close the database. Make sure no one is in the back-end. You can't safely repair or relink a file that's in use.
3. Make a backup copy of the back-end. Copy the data file to a separate folder before you touch it. This is non-negotiable. If a repair goes wrong, you want the original untouched.
4. Run Compact and Repair on the back-end. Open Access, use Database Tools, and point Compact and Repair at the back-end file itself (not the front-end). This rebuilds indexes and clears most stale-pointer cases of 3167.
5. Re-link the tables in the front-end. Use the Linked Table Manager to refresh the links so they point cleanly at the repaired back-end. If the file moved, update the path here.
6. Test the record that triggered the error. Open the exact form or query that failed and confirm the record now displays. If it does, you're done.

If the error survives Compact and Repair plus a fresh relink, the back-end has deeper damage. At that point, restoring from your most recent clean backup is usually faster and safer than fighting the corrupted file. This is exactly why a reliable backup routine matters so much with Access.

Refresh vs repair: which situation are you in?

How to stop it coming back

Clearing the error once is good. Keeping it gone is better. A few habits make a real difference:

• Run Compact and Repair on the back-end on a schedule. Weekly is sensible for a busy database. It keeps indexes healthy and heads off the stale-pointer version of 3167.
• Keep automatic backups. Daily copies of the back-end, kept for at least a couple of weeks, mean a corrupted file is an inconvenience rather than a disaster.
• Don't let users leave records open all day. Forms that sit open for hours increase the odds of a multi-user deletion clash.
• Watch the network connection. Access is sensitive to dropped connections over Wi-Fi or a flaky server link. Unstable connections are a steady source of corruption that later surfaces as errors like this one.

If your database has grown to a point where these errors keep recurring no matter what you do, that's often a sign the back-end is under more strain than an Access file is comfortable with. It doesn't automatically mean you need to move off Access, but it's worth an honest look.

When to bring in help

If you've run Compact and Repair, relinked cleanly, and 3167 still shows up, or if you don't have a recent backup and the data matters, don't keep experimenting on the live file. Each failed attempt in a damaged database risks losing more.

My team and I handle this kind of thing regularly. If you'd like a second pair of hands, you can read about how I troubleshoot and fix Access database issues and reach out from there. For existing databases I work at $40 per hour, or I can give you a fixed quote once I've seen the file. Send me a description of what you're seeing and I'll tell you honestly whether it's a quick fix or something deeper.