If your split Access database works fine in the office but corrupts frequently when accessed over VPN or remote networks, you're experiencing a common issue. This tutorial explains why Access databases corrupt over networks and provides step-by-step solutions to prevent "Unrecognized Database Format" errors.
Microsoft Access uses a file-based locking mechanism (the .LDB lock file) that requires constant, low-latency communication between the front-end and back-end database file. When this communication is interrupted or delayed, Access can't properly manage record locks, leading to database corruption.
Access's Jet/ACE database engine assumes a stable, low-latency local network connection (typically under 10ms). VPN connections add 50-200ms latency, and packet loss is common. When Access sends a lock request but doesn't receive confirmation due to packet loss, it can't determine if the lock was successful, leading to inconsistent database state.
Wi-Fi connections, especially in areas with weak signal, frequently drop packets or experience brief disconnections. When Access loses connection mid-transaction, it can't complete write operations cleanly, leaving the database in an inconsistent state.
Microsoft Access was never designed for VPN access. The Jet/ACE engine uses file-level locking that works well on local networks but struggles with the added complexity of VPN (NAT translation, encryption overhead, routing delays). This is a fundamental architectural limitation, not just a configuration issue.
Increase Access's tolerance for network delays by adjusting timeout settings:
Press Windows + R, type 'regedit', and press Enter.
Go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\[Version]\Access\Settings
Create or modify these DWORD values: 'LockRetry' (set to 20), 'MaxLocksPerFile' (set to 9500), 'LockDelay' (set to 100).
Close all Access instances and restart for changes to take effect.
Use pessimistic locking instead of optimistic locking to prevent simultaneous edits:
Open your form in Design View, go to Form Properties → Data tab, set Record Locks to 'All Records' or 'Edited Record'.
When opening recordsets, use: dbPessimistic for LockEdits parameter.
For update queries, ensure proper WHERE clauses to lock specific records.
Improve network stability for Access connections:
In VPN client settings, disable compression to reduce latency and packet loss.
For remote users, recommend wired Ethernet connections instead of Wi-Fi when possible.
Increase TCP receive window size: netsh int tcp set global autotuninglevel=normal
Use split tunneling if possible, routing only database traffic through VPN.
The most reliable solution: have users connect via Remote Desktop to a server where Access runs locally:
Install Windows Server or enable RDP on a Windows machine with Access installed.
Move the back-end database to the server's local drive (not network share).
Install Access front-end on the server, linking to local back-end.
Set up user accounts, configure firewall rules (port 3389), and test connections.
Provide users with RDP client software and connection details.
For long-term stability, migrate your Access back-end to SQL Server. SQL Server handles network interruptions gracefully:
SQL Server uses connection pooling, transaction logging, and robust error recovery that prevents corruption.
You can keep your Access forms and reports, just link to SQL Server instead of Access tables.
Use Access Upsizing Wizard or manual migration to move tables to SQL Server.
Update linked tables to point to SQL Server using ODBC or OLE DB connections.
Schedule automatic compaction to prevent database bloat that increases corruption risk:
Database Tools → Compact and Repair Database (run weekly).
Create a VBA macro or scheduled task to run compaction during off-hours.
Use Application.CompactRepair method in VBA to automate the process.
Check for orphaned .LDB files that can cause locking issues:
The .LDB file should be in the same folder as your back-end database.
If no users are connected but .LDB file exists, close all Access instances and delete the .LDB file.
Ensure users have read/write permissions to the database folder for lock file creation.
Track when corruption occurs to identify patterns:
Document exact error messages, timestamps, and which users were connected.
Review VPN logs for connection drops or high latency during corruption events.
Rapid size increases may indicate corruption or bloat.
When corruption occurs, repair immediately:
Ensure no users are accessing the database.
Copy the corrupted database file before attempting repair.
Database Tools → Compact and Repair Database.
Check critical tables and relationships after repair.
If repair fails, restore from the most recent good backup.
Remote Desktop is the most reliable method for remote Access database access.
Don't access Access databases directly over VPN if possible.
Schedule automated backups multiple times per day to minimize data loss risk.
Use network monitoring tools to track latency and packet loss.
Consider migrating to SQL Server for long-term stability and scalability.
For more information, research Access database architecture, SQL Server migration strategies, and Remote Desktop configuration best practices. Understanding the underlying technology helps prevent and resolve corruption issues more effectively.
Contact us to set up a durable Remote Desktop (RDP) or Cloud-Hosted solution. We'll eliminate network corruption and get your team back to productive work.
Get Your Solution Quote →