It worked fine in the office. Everyone was on the same network, the database sat on the file server, and everything was fast enough. Then someone started working from home, connected through VPN, and the complaints started. Slow forms. Timeout errors. Records that will not save. And eventually, the dreaded corruption.
This is not a VPN problem. It is an Access problem.
Why Access Hates Remote Connections
Access was designed as a desktop database for local area networks. The Jet/ACE engine expects fast, reliable, low-latency connections to the database file. When you access an .accdb file on a file share, the engine is reading and writing to that file constantly — not just when you save a record, but every time you scroll through a recordset, open a form, or run a query.
On a local network, the round-trip time between your computer and the file server is typically under 1 millisecond. On a VPN connection, it is 20-100 milliseconds or more, depending on the VPN technology, internet speed, and distance to the office. That does not sound like a big difference, but Access makes hundreds or thousands of small read/write operations for routine tasks. Multiply 50 milliseconds by a thousand operations and you have added 50 seconds of latency to something that took 1 second in the office.
The Specific Problems
Everything Is Slow
Opening a form that reads 500 records does not transfer 500 records in one request. Access may make dozens of small requests to read the data page by page. Each request crosses the VPN, waits for a response, and comes back. A form that opened in 2 seconds in the office takes 30 seconds from home.
Records Will Not Save
When you save a record, Access needs to lock the record (or page), write the changes, update indexes, and release the lock. This sequence requires multiple round trips to the file server. If any of those trips takes too long or fails, the save fails. Users see “Write Conflict” errors, “Record is locked by another user” messages (even when nobody else is using the record), or generic ODBC errors.
Database Corruption
This is the serious one. Access uses opportunistic locking provided by the Windows network stack to coordinate multi-user access. VPN connections are less reliable than local network connections. A momentary VPN dropout — which happens more often than people realize — can interrupt a write operation in progress. The result is a corrupted database file.
A single remote user with an unstable VPN connection can corrupt the database for everyone, including the users sitting in the office on a perfect local network.
The Locking File Disappears
Access uses a .laccdb file alongside the database to track who has the file open and which records are locked. This file is critical for multi-user coordination. VPN disconnections can cause the locking file to become out of sync, leading to phantom locks, records that appear locked when they are not, and users who appear connected when they have actually disconnected.
The Workarounds People Try (and Why They Fail)
“We’ll Just Use a Faster VPN”
A faster VPN helps somewhat, but it does not solve the fundamental problem. Even a fast VPN adds latency. And no VPN eliminates the risk of momentary disconnections. The problem is not VPN speed — it is that Access was not designed for this type of connection.
“We’ll Use Remote Desktop Instead”
This actually works — to a point. If users connect to a terminal server or remote desktop in the office and run Access from there, the database access is local to the office network. The VPN carries only the screen updates and keyboard/mouse input, not the database traffic.
The downsides: Remote Desktop licenses cost money, the user experience is not as smooth as a local application, and you are adding infrastructure complexity to work around a database engine limitation. It also means the user’s local files (for import/export) are on their home machine while Access is running on the office server, which creates its own friction.
“We’ll Use OneDrive/SharePoint to Sync the File”
This is worse than VPN. OneDrive and SharePoint sync files by detecting changes and uploading/downloading the updated file. Access databases change constantly during normal use. The sync engine and the database engine will fight over the file, and the database will corrupt. Microsoft explicitly warns against this.
“Everyone Gets Their Own Copy”
Giving each remote user their own copy of the database means the data is no longer centralized. Now you have multiple copies that need to be reconciled. Access has a replication feature, but it was discontinued after Access 2007. Manual reconciliation (export from one, import to another) is error-prone and labor-intensive.
The Actual Solution
The reason Access fails over VPN is that it is a file-based database. Every operation requires direct file access over the network. Server databases work differently. When you connect to SQL Server, MySQL, or PostgreSQL from home, your application sends a query to the server and the server sends back the results. The communication is a structured protocol (TDS, MySQL protocol, PostgreSQL protocol) designed to work over any network, including the internet.
The difference:
- Access over VPN: Hundreds of small file read/write operations per user action, each crossing the VPN. Sensitive to latency and disconnections.
- Server database over VPN (or internet): One query sent, one result set returned per user action. Tolerant of latency. Handles disconnections gracefully.
Migrating the data tables to a server database and keeping the Access front-end solves the remote work problem immediately. Remote users connect to the server database via ODBC — the same way local users do. The server handles locking, concurrency, and data integrity. A VPN dropout does not corrupt anything because the server manages its own files locally.
If your office already has SQL Server, the remote user’s Access front-end simply connects to it over VPN. The VPN carries only the query traffic, which is minimal compared to file-level access. Performance is dramatically better, and corruption risk drops to near zero.
For even better remote performance, the server database can be hosted in the cloud (Azure SQL, Amazon RDS, etc.), which eliminates the VPN entirely. Users connect directly to the cloud database from wherever they are.
The Takeaway
Remote work is not going away. If your business depends on an Access database and some or all of your users work remotely, you have a structural problem that VPN tuning and workarounds will not fix. The solution is to move the data to a database engine that was designed for networked, multi-user access — because Access was not.