If your Access database lives on a network share and more than two people use it, you've already experienced the symptoms: slowness that defies logic, mysterious "database is locked" errors, and that sinking feeling when you open it on Monday morning and it won't open at all. You're not imagining it — shared-network Access databases are fragile by design, and the problems compound as teams grow.
This post covers why shared Access databases fail, what you can do to stabilize yours, and the honest signal that tells you it's time to move to something built for real multi-user access.
Access isn't a client-server database. It's a file-format database — meaning the entire .mdb or .accdb file has to travel across the network wire every time someone reads or writes data. When only one person uses it, this is fine. When three people are editing forms simultaneously, the engine has to coordinate who's allowed to write to which 4KB page of the file at any given moment.
That coordination happens through a lock file (.ldb for .mdb, .laccdb for .accdb). On a local disk, this is fast. On a network — even a gigabit LAN — any latency spike during a write can cause the lock to be held longer than expected. Another user arrives, gets a conflict, and one of two things happens: they get an error, or the write silently fails and leaves the file in a partially-written state.
The partially-written state is corruption. And it accumulates.
A brief network hiccup while a write is in progress is the most common cause of corruption. The file is mid-write, the connection drops, and the engine doesn't get the chance to finalize the transaction. You'll see it as "Unrecognized database format" errors or tables that open but return no data.
If a user's machine crashes or they close their laptop without properly exiting Access, the lock file stays behind. Everyone else gets a "Could not use — file already in use" error even though the database is empty. The fix is to delete the .ldb or .laccdb file — but that requires someone knowing what to look for.
By default, Access uses pessimistic page-level locking: when someone edits a record, it locks a 4KB chunk of the file that might contain 10–20 other records. Nobody else can edit anything on that page until the first user saves. With more than a few users, this creates artificial bottlenecks even when people are working on completely different records.
Every form you open, every query you run — the engine has to read from the network file. Add five users, and you've multiplied the network traffic fivefold. Most people don't notice until user #4 or #5 joins and suddenly everyone's experience degrades at once.
If you can't migrate yet, these steps will buy you meaningful stability:
Before you split, make sure you're on the modern format. LegacyLeaps converts .mdb to .accdb while preserving your VBA macros, queries, and linked tables — with a free scan that shows you exactly what's inside before you commit.
Try the Free ScanThe steps above extend the life of a shared Access database. They don't change the fundamental architecture. There's a ceiling, and it's lower than most teams expect.
| Team Size | Concurrent Writers | Reality |
|---|---|---|
| 1–3 users | 1–2 | Stable with proper setup |
| 4–8 users | 3–5 | Manageable if split and tuned |
| 9–15 users | 6–10 | Frequent locks, degraded performance |
| 15+ users | 10+ | Active corruption risk — migrate now |
If your team has grown past the "manageable" tier, or if the data in this database has become genuinely business-critical (customer records, financial transactions, regulatory data), you're carrying a risk that stabilization can't address.
The Access front-end stays; the back-end tables move to SQL Server. Users see no change — they still open the same forms and run the same reports. But the data engine is now a real client-server database that handles hundreds of concurrent connections. Microsoft provides the SQL Server Migration Assistant (SSMA) for Access to automate the data transfer. Read our full guide: Migrating an Access Database to SQL Server.
This is the bigger move, but it's the one that eliminates the problem class permanently. A web app runs on a server; users access it through a browser. No file on a network share. No lock files. No Access installation required. Everyone can work simultaneously without conflicts, including remote workers and people on mobile devices.
This is what AccessLeap does — it analyzes your existing Access database and generates a modern web application that preserves your business logic: your forms, your queries, your reports, your workflows. You're not starting over from scratch; you're lifting what works into an architecture that can scale.
AccessLeap analyzes your .mdb or .accdb and shows you exactly what can be converted to a modern web application — your forms, queries, reports, and business logic. See the analysis before you decide.
Analyze My Database FreeAccess has built-in SharePoint list publishing. It works for simple lookup tables and lightweight forms, but it doesn't handle complex queries, subforms, or VBA well. If your database is genuinely simple, this is a low-cost option. If it's anything beyond that, you'll hit walls quickly.
Start with these questions:
Access uses page-level file locking — it locks a 4KB chunk of the file whenever anyone reads or writes. On a network, even small latency spikes can cause write conflicts that corrupt the file. Splitting the database so only data (no forms or reports) lives on the server dramatically reduces the network traffic and the corruption risk.
Microsoft's guidance is 5–10 simultaneous users for a properly split database on a fast LAN. In practice, 3–5 concurrent writers is where most databases start showing slowness and intermittent locks. If you're at 10+ concurrent users, you're in active-risk territory.
Splitting keeps Access as your engine but separates the data file — it helps with smaller teams but doesn't change the fundamental file-based architecture. Migrating to SQL Server replaces the engine with a proper client-server database that handles hundreds of concurrent connections without file locking.
Look for a .laccdb (or .ldb for .mdb) lock file in the same directory as the database. If all users are confirmed out and the lock file still exists, delete it — it's a stale lock from an abnormal exit. If someone is still in the database, the lock file will list their machine name and you'll need them to exit cleanly first.
Practical fixes for legacy Excel and Access problems. No spam.