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.