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 few weeks, the file is not the problem. We deliver a fixed-scope stability fix—typically from $1,200—covering deployment hardening or SQL Server when the shared file has outgrown the network.
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.
Call us at +1 (385) 386-3860
- FocusWe fix the cause, not just this week's file
- AssessmentFree, and usually same business day
- HandlingWe work on copies, never your original
Quick answer: A split Access database corrupts over a network because every PC writes directly into a shared back-end file, and any mid-write interruption (Wi-Fi drop, VPN reconnect, sleeping laptop, sync client, or antivirus) can leave it inconsistent. Excel Access Expert scopes a fixed-price stability engagement—free assessment, typically from $1,200—to harden deployment or move data to SQL Server while keeping Access screens. Symptom rows below triage the pattern; recurring remote damage usually ends with Access to SQL Server migration. For a written keep-or-move plan, use our MS Access consultant.
Access specialists since 2011 (15+ years). Last updated October 22, 2026.
A repaired database that corrupts again a few weeks 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 can land in the middle of a write.
Quick diagnosis: what you are seeing and what it usually means
Corruption has patterns. Matching yours to one of these rows tells you where to look first.
| What you notice | Most likely cause | Check first |
|---|---|---|
| Breaks after someone works from home or over VPN | Latency and dropped tunnel mid-write | Whether that person opens the back end directly |
| Breaks even with everyone wired in the office | Shared front end, antivirus or backup touching the file, server caching | Where each user's front end actually lives |
| Conflicted copies or files that "revert" | Back end in OneDrive, Dropbox or SharePoint | Whether the data file is inside a synced folder |
| Started after a server, NAS or Windows update | SMB caching or file-sharing changes | What changed on the server, and when |
| Same table keeps showing #Deleted or bad records | Attachment, OLE or very large Long Text fields | Field types in the damaged table |
| More than about ten people editing at once | Design has outgrown a shared file | Peak concurrent users |
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 moves far more data across the network 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 (.laccdb) is left behind, the next user is refused or sees 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.
Sync clients, backup software and antivirus
OneDrive, Dropbox, Google Drive and SharePoint sync folders copy and lock files in the background, which does not mix with a shared Access file. Backup agents that copy the file while it is open, and real-time antivirus scanning of .accdb and .laccdb files, can do the same thing quietly. If the problem has no obvious pattern, this is the first place to look.
Risky field types and file-server behaviour
Attachment fields, OLE Object fields and very large Long Text columns are more fragile than ordinary data, and a back end full of embedded files grows toward the 2 GB limit quickly. On the server side, older file servers, NAS devices and some SMB caching settings have a history of mishandling shared Access files. This is one for your IT provider, and it is worth asking them what changed before the corruption began.
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 and habits that reduce the symptoms
These make a fragile setup more tolerable. They do not remove the cause, and you should know the difference before you spend a week on them.
Put a copy of the front end on every user's PC (ideally compiled as .accde), never run it from the share.
Keep the back end out of OneDrive, Dropbox, Google Drive and SharePoint sync folders.
Ask IT to keep real-time antivirus scanning and open-file backup copies away from the back-end .accdb and its .laccdb lock file, and use a proper VSS-based backup instead of copying a file that is in use.
Use wired Ethernet for anyone who edits data regularly, and stop workstations sleeping while the database is open.
Leave forms on the default No Locks (optimistic) setting unless you have a reason. Edited Record (pessimistic) locking increases lock traffic and contention.
On slow links, IT can raise the Access Connectivity Engine lock settings in the registry (MaxLocksPerFile, LockRetry and LockDelay; the defaults are 9,500, 20 and 100 ms). Back up the registry first and apply the same values on every PC.
Replace Attachment and OLE fields in the back end with file paths to documents stored in a normal folder.
Compact the back end on a schedule, when nobody is connected, and always against a fresh copy.
Keep one persistent connection to the back end
Access opens and closes the back-end file repeatedly as users move between forms. Holding a single connection open for the whole session is a long-established way to cut that churn and speed things up. This is a simplified version of what we use:
' Keep one connection to the back end open while the front end is running.
' This stops Access from repeatedly opening and closing the shared file,
' which is where many dropped-connection corruptions begin.
Private mdbBackEnd As DAO.Database
Public Sub OpenBackEndConnection()
Dim backEndPath As String
On Error GoTo ErrHandler
If Not mdbBackEnd Is Nothing Then Exit Sub
' Read the back-end path from any linked table (tblSettings is an example)
backEndPath = Mid$(CurrentDb.TableDefs("tblSettings").Connect, Len(";DATABASE=") + 1)
Set mdbBackEnd = DBEngine.OpenDatabase(backEndPath, False, False)
Exit Sub
ErrHandler:
MsgBox "Cannot reach the data file. Check your network connection " & _
"and try again.", vbExclamation
End Sub
Public Sub CloseBackEndConnection()
On Error Resume Next
mdbBackEnd.Close
Set mdbBackEnd = Nothing
End Sub
' Call OpenBackEndConnection from your startup form's On Open event
' and CloseBackEndConnection from the On Close event.Test on a copy first. This reduces churn; it does not make a Wi-Fi drop safe.
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. Remove sync, backup and antivirus interference
Take the back end out of synced folders and stop other software locking it while people are working.
5. Tune locking and connection behaviour
Sensible record locking, lock retry settings where they help, and a persistent connection to the back end so the link is not torn down and rebuilt all day.
6. Move the data to SQL Server or Azure SQL
The back end becomes a real database server, the Access forms your staff know stay as they are, and a dropped connection no longer risks the data file.
Work is performed on backup copies only - secure handling, nothing shared with third parties.
Why moving the data to SQL Server stops the corruption
With a shared Access file, every user's PC writes directly into the data file, so any interrupted write can damage it. With SQL Server or Azure SQL, only the server process writes to the data, and every change is a transaction. If a user's connection drops halfway through, the server rolls the change back and the file is untouched. Your Access forms and reports keep working; they just read and write through the server instead of through a shared file.
It is not magic. A VPN is still slower than a wired LAN, and queries written for a local file sometimes need tuning once the data sits on a server. But the failure mode changes from a damaged database to a slow screen or a retry, and that is a trade almost every team is happy to make.
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 2 GB 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 staff need a browser or mobile interface instead of Windows desktops, a web front end on the migrated data is the other route. 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 Compact and Repair fails, see Compact and Repair not working; 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 turn Access into a client-server system. Each front end still reads and writes pages of the back-end file directly across the network and expects that connection to behave like a local disk. Any interruption mid-write, such as a dropped Wi-Fi association, a VPN renegotiation, a switch port flapping, or a laptop going to sleep, can leave the file inconsistent. The corruption is rarely a sign that the split was done badly. It is a sign that the network is less reliable than a local disk.
Because the remote user is the one on the least reliable link. A VPN adds latency and encryption overhead, and Wi-Fi at home drops and reconnects without anyone noticing. Access cannot retry a half-finished write to a shared file the way a browser retries a page. If corruption lines up with one person's remote sessions, that connection is almost certainly where the file is being damaged.
For Access, yes. Wi-Fi drops and re-associates in ways users never notice, because most software simply retries. Access writes to a shared file with no way to recover a partial write. A wired connection removes most of that risk, which is why we recommend Ethernet for anyone who edits data in the database directly.
Opening an Access back end across a VPN is the setup behind most of the corruption calls we get, and it is slow as well, because Access pulls far more data across the link than people expect. For a remote team the safe options are a remote desktop session on a machine that sits next to the data, or moving the data to SQL Server or Azure SQL. Both remove the cause rather than working around it.
No. Sync clients copy, lock and replace files in the background, which conflicts with how Access holds a shared file open. This is a well-known cause of corruption and of conflicted copies appearing next to your database. The back end should live on a proper file server or network share, or better, in SQL Server. The front end should be a local copy on each PC.
They can make a marginal setup more tolerable. Raising lock retry and lock delay gives Access more patience on a slow link, and raising MaxLocksPerFile avoids a common error on large updates. They do not remove the cause. Treat them as making a bad situation survivable while you fix the architecture, and have IT back up the registry before changing anything.
No. Compact and Repair rebuilds the file and can recover a damaged database, but it does nothing about whatever damaged it. If you are repairing the same database every few weeks, the repair is a symptom treatment. Always take a copy before running it. If it fails, see our guides on repairing a corrupt Access database and on Compact and Repair not working.
As a rule of thumb, on a properly split database, over a wired local network, with a front end on each desktop, around five to ten people working at the same time is realistic. Beyond that, lock contention, slow forms and corruption risk 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 use.
With a shared Access file, every user's PC writes directly into the data file. With SQL Server, only the server process writes to the data, and every change is a transaction. If a user's connection drops halfway, the server rolls that change back and the data file is untouched. Your Access forms stay as they are. They simply read and write through the server instead of touching a shared file.
Many small Access databases fit comfortably in SQL Server Express, which is free but limits each database to 10 GB. Azure SQL Database is the other common choice when staff are remote and you do not want to run a server. We size this during the assessment based on your data volume, user count and growth, and put the recommendation in writing.
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
15+Years Experience
FixedScope Quotes
2011Established
Prefer to talk? Call us at +1 385 386 3860