Multiuser application design strategies for Microsoft Access

When you develop applications that multiple users will access over the network, you must make sure they effectively handle sharing data and other application objects. Many options are available for developers when they design multiuser applications, and this chapter covers the pros and cons of these options.

Multiuser issues revolve around locking data; they include deciding where to store database objects, when to lock data, and how much data to lock. In a multiuser environment, having several users simultaneously trying to modify the same data can cause conflicts. As a developer, you need to handle these conflicts. Otherwise, your users will experience unexplainable errors.

Multiuser application design strategies

There are many methods for handling concurrent access to data and other application objects by multiple users; each one offers both solutions and limitations. It's important to select the best solution for your particular environment.

Strategies for installing Microsoft Access

• Run Microsoft Access from a file server across a network.
• Run a separate copy of Microsoft Access on each workstation.

The advantages of running Microsoft Access from a file server are that it

• Allows for central administration of the Microsoft Access software
• Potentially reduces the licensing requirements
• Allows Microsoft Access applications to be installed on diskless workstations
• Reduces hard disk requirements

File server installations also have serious drawbacks, including the following:

• Every time the user launches an Access application, the Access EXE, DLLs, and any other files required to run Access are all sent over the network wire to the local machine. Obviously, this generates a significant volume of network traffic.
• Performance is generally degraded to unacceptable levels.

Because the disadvantages of running Microsoft Access from a file server are so pronounced, I strongly recommend that you install Microsoft Access, or at least the runtime engine, on each user's machine.

Strategies for installing your multiuser application

Just as there are different strategies for installing Microsoft Access, there are also various strategies for installing your application, such as the following:

• Install both the application and data on a file server.
• Install the data on the file server and the application on each workstation.
• Install the application and the data on a machine running Windows 2003 Terminal Services.

In other words, after you have created an application, you can place the entire application on the network, which means that all the tables, queries, forms, reports, macros, and modules that make up the system reside on the file server. Although this method of shared access keeps everything in the same place, you will see many advantages to placing only the database's data tables on the file server. The remaining objects are placed in a database on each user's machine, and each local application database is linked to the tables on the network. In this way, users share data but not the rest of the application objects.

The advantages of doing this are as follows:

• Because each user has a copy of the local database objects, load time and network traffic are both reduced.
• You can easily back up data without having to back up the rest of the application objects.
• When redistributing new versions of the application, you don't need to worry about overwriting the application's data.
• You can design multiple applications to use the same centrally located data.
• Users can add their own objects (such as their own queries) to their local copies of the database.

In addition to storing the queries, forms, reports, macros, and modules that make up the application in a local database, I also recommend that you store the following objects in each local database:

• Temporary tables
• Static tables
• Semistatic tables

Temporary tables should be stored in the database that's on each workstation because, if two users are performing operations that build the same temporary tables, you don't want one user's process to interfere with the other user's process. You can eliminate the potential conflict of one user's temporary tables overwriting the other's by storing all temporary tables in each user's local copy of the database.

You should also place static lookup tables, such as state tables, on each workstation. Because the data doesn't change, maintenance isn't an issue. The benefit is that Access doesn't need to pull that data over the network each time the application needs it.

Semistatic tables—tables that are rarely updated—can also be placed on the local machine. As with static tables, having these tables in a local database means reduced network traffic and better performance, not only for the user needing the data, but also for anyone sharing the same network wire.

The configuration described throughout this section is illustrated in Figure 22.1.

Figure 22.1 An example of a configuration with database objects split, storing temporary and static tables locally and shared tables remotely (on the file server).

Terminal Services has emerged as a viable alternative for deployment of an Access application. It addresses both bandwidth and centralization issues. With this option, a Windows 2003 machine runs the Windows 2003 Terminal Services. Client machines then access the server machine using the Terminal Server Client Utility. In this scenario, Access, your application, and the data that it accesses are all installed on the Windows 2003 Server machine. All other machines access the application via user sessions created on the server machine. Keystrokes and mouse events are sent from the client machines to the server machine. The resulting screen image is returned to the client machine. This configuration addresses many of the problems inherent in the two other solutions.

• Continue reading about multiuser application design strategies for Miscrosoft Access
• Read other excerpts from data management books in the chapter download library