Split MS Access Application

The Split MS Access approach is a superior method for deploying MS Access applications within a LAN environment (among a relatively small group of End Users). This approach requires "splitting" the MS Access application into 2 MDB files: one that contains the Front-End Application components (User Interface Forms, Queries, code, etc.) and another MDB file that contains the Back-end datastore component.
Splitting an MS Access application into front-end and back-end components can incrementally improve application reliability, but can come at the cost of performance. Generally speaking, splitting an MS Access application is a good idea to support small LAN workgroup environments.
Split MS Access Application Scorecard
# End Users 5-10 Additional users will degrad all metrics
Deployment LAN Only WAN not recommended
Performance Varies # of users, records, and datastore size dependent
Reliability Med Not recommended for business critical applications
Data Integrity Poor Limited means to insure data quality and completeness
Security Poor Data is wide open to the LAN
Data Limit < 200 MBs More data will impede performance and reliability
Maintenance High Frequent Repair & Compact, Restore
# of Records < 50,000 More records will impede performance and reliability
Internet Access No Remote access will substantially impede performance and reliability

Sharing Data With a Split MS Access Application

It is fairly common to use the Split Access method to support different MS Access Front-End applications that are connected to a single back-end MS Access datastore. For example, a single MS Access datastore that contains Customer Contact data connected to different MS Access applications in the Marketing and Customer Support departments.
The benefits of splitting an MS Access application are limited: you cannot share the application across a Wide Area Network (WAN) or scale application use beyond a dozen or so simultaneous users.

In addition, Split MS Access Applications are NOT HIPAA Compliant!