HomeServicesTechnologyAnalyticsOur ClientsAbout PCAContact Us

Standalone MS Access Application

MS Access applications are constructed around a single MDB file that contains both the front-end User Interface Forms, Queries, code, etc., and the back-end datastore component (Jet Engine).  This is how MS Access is configured out-of-the-box (absent a design decision, this is what you will get).  The default MS Access configuration is perfectly suitable for small work groups in a LAN environment, provided you do not exceed one or more built-in limitations of MS Access i.e. size of datastore, number of records, etc.
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 small set of users grows in the number of users, complexity of the application (ad hoc features), and size of the MS Access datastore.
Standalone MS Access Application Scorecard
# End Users 5-10 Additional users will degrad all metrics
Deployment LAN Only Single site (OK), Multi-sites (Migrate)
Performance Varies # of users, records, and datastore size dependent
Reliability Good 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

Supporting Multiple Users With Standalone MS Access Application

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 only well-intentioned users from harming the MS Access application.  In addition, new multi-user class capabilities will become necessary e.g. remote access, enhanced security, improved data integrity and application performance... capabilities that were unnecessary or irrelevant to the original design of the MS Access application.

Providing Internet Access to a Standalone 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 MS Access application. Over time, this workaround will only exacerbate problems, and force a decision to upsize the MS Access application to a more appropriate multi-user configuration.