1. Split the database properly
Data in one back-end file on the server, and a front end containing forms, queries, reports and code. Non-negotiable before anything else.
Access stability
Your Access Database Keeps Corrupting Over the Network, Wi-Fi or VPN
If you are repairing the same database every week, the file is not the problem. Access writes to a shared file as though it were a local disk, and the network keeps proving otherwise.
Corrupting every few days and the team is stuck? Call +1 385 386 3860 and we will look at the deployment, not just the file.
- FocusWe fix the cause, not just this week's file
- AssessmentFree, and usually same business day
- HandlingWe work on copies, never your original
A repaired database that corrupts again a week later is not a repair problem. Access does not talk to a back-end file the way a web application talks to a database server. Each desktop reads and writes pages of that shared file directly, and it assumes the connection is as dependable as a local drive. On a wired LAN that assumption mostly holds. Over Wi-Fi or a VPN it fails regularly, and every failure lands in the middle of a write.
What actually causes it
Dropped and re-established connections
Wi-Fi clients drop and re-associate routinely. Browsers and mail clients hide this by retrying. Access cannot retry a partially completed write into a shared file, so an interruption at the wrong moment leaves the structure inconsistent. This is why the person on the laptop in the far office is so often the one who breaks the database.
Latency and packet loss
Access chats across the network far more than people expect, and a query that feels instant locally can pull a large amount of data across the link. Add latency and occasional packet loss, and operations take long enough to collide with each other or time out midway. VPN links make this markedly worse because every packet carries encryption overhead on top of the round trip.
Machines sleeping or being closed mid-edit
A laptop lid closed while a form is open, or a workstation that sleeps on a timer, ends the session without releasing locks cleanly. The lock file is left behind, the next user is refused or gets stale state, and the file is a little more inconsistent than it was.
A front end running from the network share
Splitting only helps if each person runs their own copy of the front end locally. When everyone opens the same front-end file from the server, every form, query and line of code is pulled across the network by every user, multiplying both the traffic and the chances of a bad write. We find this in a large share of the databases we are asked to stabilise.
An unsplit database shared by several people
If forms, code and data are still in one file that several people open from a share, corruption is a matter of time. Splitting is the minimum before anything else is worth trying.
Settings that reduce the symptoms
These make a fragile setup more tolerable. They do not remove the cause, and we would rather you knew the difference.
Give Access more patience on a slow link by raising its lock retry and locks-per-file limits, and adding a short lock delay.
Set record locking deliberately on busy forms rather than leaving the default, so edits contend less.
Let Windows tune the TCP receive window rather than leaving it constrained on the server or clients.
Prevent workstations from sleeping while the database is open, and discourage closing laptop lids mid-edit.
Move anyone who works in the database regularly onto wired Ethernet rather than Wi-Fi.
The fixes that actually end it
In the order we normally apply them
From deployment hygiene to removing the shared-file dependency entirely.
2. Put a front end on every desktop
Each person runs their own local copy, updated automatically when you release a new version. This alone removes a large share of the network traffic.
3. Get the writers off Wi-Fi and VPN
Anyone editing data works over a wired connection, or through a remote desktop session on a machine sitting next to the data rather than across a tunnel.
4. Tune locking and connection behaviour
Retry limits, record locking on forms, and keeping a persistent connection to the back end so the link is not torn down and rebuilt all day.
5. Move the data to SQL Server when it has outgrown a file
The back end becomes a real database server, the Access forms your staff know stay exactly as they are, and a dropped connection no longer risks the data.
Work is performed on backup copies only - secure handling, nothing shared with third parties.
When to stop patching and move the data
A shared file is the right answer for a handful of people on one wired network. It stops being the right answer when more than about ten people work in it at once, when anyone needs to work remotely, when the file keeps approaching the 2GB limit, or when the cost of a day of downtime has grown beyond the cost of fixing it properly. At that point the data belongs in SQL Server with Access kept as the front end - see Access to SQL Server migration. If you want the trade-offs written down before committing budget, that is what a Microsoft Access consultant engagement is for.
What it costs
Fixed-scope project estimates based on the business value we deliver. Projects typically start at $1,200 - smaller fixes can be less, larger systems more.
The assessment is free and you get the figure in writing before billable work starts. If the file is currently damaged, start with Access database repair; if it will not open at all, see unrecognized database format recovery. If it opens but is slow rather than broken, optimising the database is the better starting point.
FAQ
Frequently Asked Questions
Find answers to common questions about our services
Splitting is necessary but it does not make Access a client-server system. Each front end still reads and writes pages of the back-end file directly across the network, and it expects that connection to behave like a local disk. Any interruption mid-write - a dropped Wi-Fi association, a VPN renegotiation, a switch port flapping, a laptop sleeping - can leave the file inconsistent. The corruption is not caused by splitting being done wrong; it is caused by the network not being as reliable as a local disk.
Yes, and it is the single most common factor we find. Wi-Fi drops and re-associates constantly in ways users never notice, because a browser or email client simply retries. Access cannot retry a half-finished write to a shared file. A wired connection removes most of the problem, which is why we recommend Ethernet for anyone working in the database directly.
Opening an Access back end across a VPN is the arrangement that produces the most corruption calls we get, and it is also painfully slow because Access pulls far more data across the link than people expect. If your team is remote, the right answers are a remote desktop session on a machine near the data, or moving the data to SQL Server. Neither is a workaround; both remove the cause.
They reduce the frequency of lock conflicts and can make a marginal setup more tolerable. Retry and lock-per-file values give Access more patience on a slow link, and setting record locking deliberately on forms reduces contention. Treat these as making a bad situation survivable while you fix the real architecture, not as a solution in themselves.
On a properly split database, over a wired local network, with a front end copied to each desktop, about five to ten people working at the same time is realistic. Beyond that, lock contention, slow forms and corruption risk all climb. If you are past that number, or anyone connects remotely, the data belongs in SQL Server with Access kept as the screens your staff already know.
We quote a fixed price for a defined piece of work rather than billing hourly. Fixed-scope project estimates based on the business value we deliver. Projects typically start at $1,200 - smaller fixes can be less, larger systems more. The assessment is free: we look at how the database is deployed, how people connect, and how much data there is, then tell you in writing whether this is a deployment fix or a case for moving the data.
Tired of repairing the same database?
Tell us how it is deployed and who connects from where. We will tell you whether this is a deployment fix or time to move the data.
1
15-min audit
→
2
Fixed-scope quote
→
3
Deliver outcome
20+Years Experience
500+Projects Delivered
FixedScope Quotes
1 HourResponse Time
Prefer to talk? Call us at +1 385 386 3860