Lock errors
Lock errors on shared back-ends block order entry and shipping. Here is what causes them and how teams stop the weekly fire drill.
The "could not lock file" message usually appears when two or more users need write access to the same Microsoft Access back-end on a network share at the same time. It is common in order entry, shipping, and inventory workflows where departments open the database within minutes of each other. Short-term fixes (Compact and Repair, kicking sessions, copying the file locally) rarely stick. This guide explains why the error happens, what you can do this week, and when SQL Server or a web app is the durable fix.
Access uses file-level locking on .accdb and .mdb back-ends. When User A has a record open for edit, User B may be blocked from opening the back-end or saving changes. On a LAN share the problem feels random because timing matters: two people opening the same table for write within seconds is enough to trigger the error.
The error is worse when someone leaves Access open overnight, a laptop sleeps mid-edit, or a remote user pulls the file over VPN. IT often sees three copies of the database on different machines because staff stop trusting the share.
These steps reduce noise but do not change the underlying limit: many concurrent writers on a Jet file.
If you still run a single .accdb on a share, split it. Users open a front-end from their PC; tables stay linked to one back-end. See our split database guide for linked-table path rules and deployment habits.
Choose SQL when the team wants to keep Access forms but needs reliable multi-user writes, scheduled backups, and room past the 2 GB file limit. Linked tables behave like today; locking moves to SQL Server. Typical fit: 10–40 users, write-heavy workflows, finance still comfortable in Access for 12–24 months.
Access to SQL Server migration is often phase one before a full web program.
Choose web when you want browsers on tablets, no Access license on each PC, and HTTPS access for remote staff. Order entry and field workflows are common first modules. Read a related manufacturing case study for a phased example.
Document who hits the lock error, which form they use, and how often. Send front-end and back-end files for a written recommendation: hosted bridge, SQL upsize, or web pilot. Contact us or use the pricing calculator after you count forms and reports.
For delivery help, see our MS Access Migration Services.
FAQ
Splitting front-end and back-end is required for multi-user Access, but it does not remove Jet/ACE file locking limits. It reduces corruption risk and simplifies deployment. If more than a handful of users write concurrently, SQL upsize or web conversion is usually next.
Hosted desktop puts one golden copy of the database in a controlled environment so users are not syncing local files. It is a strong bridge when you need everyone on live data this month while SQL or web is scoped.
Typical mid-size split databases move to SQL in four to eight weeks including staging validation and a Saturday cutover. Scope depends on table count, VBA using local tables, and integration count.