MS Access applications are constructed around a single MS Access MDB file that contains the front-end User Interface Forms, Queries, code, etc., and the back-end MS Access data store component. This is how MS Access is configured by default (absent a decision, this is what you will get).

It is quite common for an MS Access application to begin life as a single User productivity tool, and, as more and more people see the benefit of using the application, morph over time into a multi-user application. Real problems start to occur when an MS Access application that was originally designed for a single User grows in the number of Users, complexity (ad hoc features), and size of the MS Access data store.

A Standalone MS Access Application is particularly difficult to maintain in multi-user environments. For example, data is frequently lost or overwritten, application updates are difficult to deploy, and security is limited to protecting well-intentioned End Users from harming the MS Access application. In addition, new multi-user class capabilities become necessary e.g. remote access, enhanced security, improved data integrity and application performance... capabilities that were unnecessary or completely irrelevant to the original business intent of the MS Access application.

Standalone MS Access Application Scorecard
Number of End Users	<5	More Users = linear degradation of all metrics
Application Performance	Good	Poor application design will impede performance
Application Reliability	Good	Increased usage and datastore size will crash the application/corrupt the datastore
Data Integrity	Poor	Limited means to insure data accuracy
Application Security	Poor	Data wide open to the LAN
Maintenance Burden	High	Repair & Compact, Restore common

A very common multi-user workaround for a Standalone MS Access application is to provide remote User access to the application via Citrix, Terminal Services, etc. While this does solve the immediate multi-user deployment need, it does not address problems inherent to sharing a single-user designed application. Over time, this common workaround will only exacerbate problems, and force a decision to properly migrating the MS Access application to a more appropriate multi-user environment.