The Standalone MS Access Application

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. 

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.

See the 10 Most Common Application Migration Business Drivers