Split database

Access Split Database Setup: Best Practices for Multi-User Stability

Learn split-database best practices, common mistakes, and when to move beyond front-end/back-end Access.

FE/BE splitNetwork sharesStability

Book free consultation View access problems & fixes service

Reviewed by MSAccessOnline migration team · Last updated May 2026

Splitting a Microsoft Access database into a front-end (forms, reports, code) and a back-end (tables on shared storage) is the standard first step toward multi-user stability. Done well, it reduces corruption tied to shared front-ends and simplifies updates. Done poorly, it only moves the pain to the back-end file. This guide covers correct setup, mistakes we see in reviews, and when to move to SQL or a web application.

What split database means in practice

Before split, one .accdb contains everything. After split, table data lives in a back-end file on a server share or hosted path. Each user opens a front-end that links to those tables. Queries, forms, reports, and VBA stay in the front-end, so you can redeploy UI fixes without copying the full data file to every desktop.

Back-end: tables, relationships, and optionally static lookup data
Front-end: UI, queries, macros, modules, linked table definitions
Connection: linked tables with consistent UNC or managed drive paths

Split does not change the Jet/ACE concurrency model. It organizes files so updates are safer. Heavy write load still hits one back-end .accdb unless you upsize to SQL.

When splitting is worth it

Split early if more than one person uses the database daily, you deploy form changes often, or IT needs a clear backup target (the back-end only). Stay unsplit only for true single-user tools or prototypes with no production SLA.

If users already report lock conflicts, read MS Access multi-user problems in parallel. Split fixes distribution problems; it may not fix contention by itself.

Correct setup steps

Full backup of the unsplit database with all users disconnected
Run Compact and Repair on a copy; resolve obvious corruption before split
Use the Database Splitter wizard or manual move tables to back-end, link in front-end
Place back-end on governed storage with nightly backup and documented UNC path
Distribute front-end copies per machine or via controlled installer
Test linked tables from each network segment (office, VPN, hosted desktop)
Document relink procedure for IT when the share moves

After split, add a startup routine in the front-end that verifies back-end connectivity and shows a clear error if the path is wrong. Silent failures frustrate users and create phantom support tickets.

Common mistakes to avoid

These patterns cause more downtime than staying unsplit:

One front-end file on a shared drive opened by multiple users simultaneously
Hard-coded drive letters (S:) that differ between laptops and Citrix sessions
No version control when a developer ships a new front-end without telling the team
Back-end on a slow VPN share while users save continuously from remote sites
Backups that copy the .accdb while users are connected, producing unrestorable files
Mixing production and test tables in the same back-end without access discipline

Split database deployment patterns

Pattern	Stability	Update effort	Verdict
Local FE per PC, BE on LAN	Good for small teams	Medium	Recommended baseline
Shared FE on network drive	Poor	Low until it breaks	Avoid
FE on Citrix, BE on same farm	Moderate	Low if scripted	Acceptable with governance
FE local, BE over VPN	Poor under write load	Medium	Plan SQL or web
FE linked to SQL BE	Strong	Medium	Best bridge architecture
Browser app, SQL BE	Strongest	Central deploy	Long-term target

Reliability practices that actually help

Publish front-end updates on a schedule; keep a rollback copy
Index foreign keys and fields used in WHERE clauses on busy forms
Shorten record locks: close forms after save, avoid continuous form scroll on huge sets
Run long reports from read-only snapshots or replica exports where possible
Monitor back-end size monthly; plan SQL before the 2 GB wall
Test restore, not just backup file existence

Pair split discipline with corruption awareness. If repair events are recurring, see Access database corruption fix for root-cause patterns that split alone cannot solve.

Unsure whether your split setup is production-safe?

Request architecture review

When split architecture is no longer enough

Split is a file-organization strategy, not unlimited scale. Teams usually outgrow it when:

Concurrent writers exceed what the back-end file tolerates without lock storms
Remote users depend on high-latency file shares for every save
Back-end size or attachment volume approaches Access limits
Compliance requires row-level audit, encryption at rest, or granular roles SQL provides
Leadership wants browser access without installing Access on every device

At that stage, upsizing data to SQL Server while keeping Access forms is a proven bridge. The end state for many businesses is a web application on the same database, which removes front-end distribution entirely.

Migration path beyond split

A practical sequence minimizes disruption:

Stabilize split and backups; document peak users and lock-heavy forms
Migrate tables to SQL; relink Access front-end; validate reports
Convert the worst lock offenders to web screens first
Expand web modules by department; retire shared back-end .accdb for daily use
Decommission legacy front-ends after acceptance testing and training

Phased delivery keeps finance and operations running while architecture improves underneath. Pilot one workflow with real users before committing to a big-bang cutover.

Want a roadmap from split Access to SQL and web?

Book free consultation

For split-database review and phased migration, see our MS Access Migration Services.

Frequently asked questions

What is the difference between Access front-end and back-end?

The back-end holds tables and relationships in an .accdb file on shared storage. The front-end holds forms, reports, queries, macros, and VBA, with linked tables pointing to the back-end. Each user should run a local or properly deployed copy of the front-end, not a single shared front-end on a network drive.

How do I split an Access database using the wizard?

Use Database Splitter on the back-end candidate after a full backup. The wizard creates a back-end file with tables and leaves linked tables in the front-end. Immediately verify linked table paths, relink if the share moves, and distribute updated front-ends to every user.

Why do users still get lock errors after splitting?

Splitting reduces front-end contention but the back-end is still a file-based database. Many concurrent writes, long-running reports, and VPN latency can still produce locks and corruption risk. SQL Server or a web app addresses concurrency at the engine level.

Should the back-end live on a network share or cloud drive?

Use stable, low-latency storage with documented backup and exclusive-access windows for maintenance. Cloud mapped drives and VPN file shares work only when IT enforces disconnect rules, antivirus exclusions, and monitored free space. Unreliable paths cause more damage than local office hosting.

How do we update the front-end for everyone?

Version the front-end file (date or build number in the name), publish through a script or installer, and block old versions from connecting if possible. Email attachments and manual copy-paste lead to schema drift, missing bug fixes, and mysterious errors.

When should we stop investing in split architecture?

When lock complaints persist after front-end discipline, user count grows past roughly ten concurrent writers, remote workers depend on VPN file access, or the back-end file approaches 2 GB. Those signals mean split was the right first step, not the final architecture.

Book a free consultation MS Access Migration Services