Given the possibility for problems with information systems, it is best that businesses and organizations respect precautions, maintenance procedures and recommendations specific to the database software products they utilize.  Mission critical data is of great importance and value, justifying proper security and protection measures.  Microsoft Access can be configured and used in a variety of ways.  What usages of Access are prone to be problematic and what is the safest way to use Access in a multi-user environment?

Those in the business of creating information systems are referred to as "database developers".  The process of enhancing and modifying a database is called "database development".  For example, consider company XYZ that has several standalone MS Access databases that were created in-house.  If one such stand-alone database fails, or becomes "corrupted", it only affects that small part of the overall business.  Hence, businesses may utilize "personal" databases existing in isolation with little concern for what could happen in the event of a problem.   In the world of the simple stand-alone database, simplicity is bliss, and concerns for protection and security are not as important as they are with shared databases.

The day comes when company XYZ would like to "graduate" a personal database for multi-user use.  If the database is simply made available to others (via a shared folder), then multiple users can open and use the database.  Is this safe?   Database "corruption" can result when an undesirable (from the perspective of software trying to do it’s job) event occurs, such as someone abruptly turning the power off - ignoring proper shutdown procedures.  The possibility for database corruption increases greatly with multiple users opening, using, and possibly modifying the same mdb file.  Hence, sharing a single mdb file for simultaneous use by multiple users is not recommended by professionals in the Access database development community.

Larger scale database management software is equipped with strategies for recovery in the event of system failures.  The Microsoft Access "database engine" is not equipped with the recovery features of large scale systems.  Is this to say that Access should ever be used for multi-user applications?  To answer that question, there are prudent ways to use Access in a multi-user environment that enable it to function quite successfully.   Again, simply sharing a single Access mdb file is not one of the safe ways to use Access.  Access has many features which make it desirable for database systems.  Table tools within Access allow for powerful data integrity, making it possible to create applications more quickly than they could be created with other larger scale database management products.

The most prudent way to use Access in a multi-user environment is to share a data-only mdb file, with the application software residing on each workstation that accesses the shared data.  This way, the single shared data-only mdb file is never opened for changes to Access application components, such as forms, reports, programs, etc.   Performing "design and modification" work in Access increases the likelihood that the database will experience "corruption".

With the application software residing on each workstation, network issues concerning the application itself are eliminated.  Networking issues could, of course, come up as the application interfaces with the single shared data-only mdb file.  Using Access in this fashion brings up the issue of application software version control.   If each user is allowed to modify the application software on his or her computer, the application software would vary from computer to computer – resulting in a version control nightmare.

It is common for businesses or organizations wishing to develop their databases to procure the services of an outside database development provider.  Larger companies may task specific staff or a department to manage the development process.  Fielding and evaluating modification and enhancement requests, programming and testing the changes, and ultimately upgrading the application software on each computer becomes the responsibility of the company or department assigned to do that job.  Such an approach helps to ensure that only needed and tested modifications are made.  Modifications and testing are done in a separate area from the "live" or "production" system, so that if something goes wrong during programming, the live or production system is not jeopardized.

Access developers can provide "runtime" software that does not require Access to be installed on each workstation.  This eliminates the need for volume licensing of Access.