Multi-user fix
How browser-based architecture removes record locking and concurrent write bottlenecks.
Record-lock dialogs and ‘database in use’ messages are symptoms of file-based multi-user limits, not careless employees. Split databases, faster networks, and polite closing of forms help temporarily , but they do not change the underlying model. A web application with a server database removes the lock file dance permanently for teams ready to modernize.
Microsoft Access uses page-level locking on shared database files. When one user edits a record, others may be blocked from related pages or see #Lock violations on open forms. WAN latency amplifies the problem: users hold locks longer while forms refresh over slow links. Front-end copies on each PC still point at one back-end .accdb on a file share , every save competes for the same file.
Our dedicated article on MS Access multi-user problems walks through symptoms, split-database mitigations, and when those mitigations stop working. The permanent fix for organizations outgrowing file concurrency is moving writes to a client-server database accessed through a web tier, not opening the .accdb on more machines.
IT teams often try shorter paths first: compact and repair, relocate the back-end to a faster NAS, enforce “close when done” policies, or deploy Citrix so everyone runs one front-end session. These reduce friction but preserve Jet/ACE semantics. As headcount and transaction volume grow, support tickets return.
| Tactic | Effort | Durability | Remote-friendly |
|---|---|---|---|
| User training / discipline | Low | Low | No |
| Compact & repair schedule | Low | Low | No |
| Split FE/BE + gigabit LAN | Medium | Medium | Partial |
| Upsize to SQL + Access FE | High | Medium | Needs hosted FE |
| Hosted Access desktop | Medium | Medium | Yes via RDP |
| Full web app + SQL | High | High | Yes native browser |
Architecture change costs more upfront than policy reminders but stops recurring lock firefights. Finance should compare support hours, downtime, and delayed projects against phased migration investment , frameworks in our cost guide help structure that conversation.
Browser clients send HTTP requests; the server opens short database transactions, commits changes, and releases locks in milliseconds. Optimistic concurrency , version columns or timestamps , detects when two users edited the same row; the second saver gets a clear conflict message instead of an opaque Access dialog. Long-running edits should autosave drafts or lock at the business-object level with timeouts, not hold database pages open while someone takes a phone call.
Read scaling improves with replicas, caching, and read-only reporting endpoints. Write bottlenecks shift to index tuning and transaction design , solvable problems DBAs handle daily. This is the operational model behind Access to web app conversion engagements.
Splitting front-end and back-end is best practice for multi-user Access but does not repeal file limits. Linked SQL backends help yet still require Access installed (or hosted) per user. Cloud desktops centralize the front-end while users RDP in , better for remote teams, same locking if everyone hits one Access back-end file. Upsizing to SQL Server with Access as UI improves data integrity; web conversion removes desktop dependency entirely.
Choose hosted Access when change must be minimal and user count is modest. Choose web when locks, corruption, remote hiring, or integration requirements dominate. Migration services document both paths without forcing one-size-fits-all.
A practical escape route: (1) stop growing the monolithic .accdb on the share, (2) upsize tables to SQL if not already done, (3) pilot the noisiest workflow in a web app, (4) migrate adjacent forms and reports, (5) retire Access for those modules. Parallel operation needs rules about which system owns master data during overlap.
Phasing controls spend , see modernization pricing for tiered bands on form/report counts in early phases.
“We have fifteen users” is insufficient for sizing. Capture peak concurrent editors, largest tables, batch jobs, and report windows. Seasonal spikes (year-end inventory) matter more than average lunch-hour usage. Web infrastructure scales vertically first, then horizontally with load balancers and read replicas when metrics justify cost.
Integration traffic (e-commerce imports, API writes) counts as concurrent load even if humans are offline. Capacity reviews should include automated jobs that used to run as hidden Access macros on one clerk’s PC.
Track lock-related tickets (should drop to zero for migrated modules), mean time to complete key transactions, login success from remote locations, and error rates on API saves. Survey users at thirty and ninety days , numeric stability plus subjective confidence. Success is not “we launched a web app”; it is “operations stopped scheduling around Access downtime.”
Tired of daily lock errors? Map a permanent fix.
Book a multi-user architecture reviewFor a scoped migration plan, see our MS Access to Web App Conversion.
It eliminates file-share locking and front-end distribution problems. Poor schema design or missing indexes can still slow queries. Web architecture fixes the Access-specific concurrency ceiling, not every data modeling mistake.
Properly designed systems on SQL backends support dozens to hundreds of concurrent users depending on workload, hardware, and query patterns. Capacity planning should use realistic peak scenarios, not license counts alone.
Split databases, SQL backends, and hosted desktops improve stability up to a point. When users still fight over writes on the same records or need browser access, web conversion addresses root cause rather than symptoms.
Web apps assume connectivity. Field offline scenarios need progressive web features, mobile apps, or deliberate offline sync design , scope this explicitly if trucks or warehouses lack reliable networks.
Server databases use transactional logs and backups unlike Jet files on SMB shares. Corruption risk drops sharply when no .accdb lives on a network folder edited by multiple clients.
A pilot workflow moved to the web can relieve the worst bottleneck in weeks while the rest of Access remains. Prioritize the forms and tables generating the most support tickets.