Alison Balteramp;#039;s Mastering Microsoft Office Access 1002003 [Electronic resources] نسخه متنی

Designing Your Application with Multiuser Issues in Mind

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 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 Access

There are two strategies for installing Access:

• Run Access from a file server across a network.

• Run a separate copy of Access on each workstation.

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

• Allows for central administration of the Access software

• Potentially reduces the licensing requirements

• Allows Access applications to be installed on diskless workstations

• Reduces hard disk requirements

NOTE

The Access software takes up a significant amount of disk space. Although using the Access runtime engine can reduce disk space requirements, local hard-disk space can definitely be a problem. Installing Access on the file server at least partially eliminates this problem. It can totally eliminate the problem if you also install dynamic link libraries (DLLs) on the file server.

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 Access from a file server are so pronounced, I

strongly recommend that you install Access, or at least the runtime engine, on each user's machine.

Strategies for Installing Your Application

Just as there are different strategies for installing 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 2000 Terminal Services or 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.

• It's very easy to 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 tablestables that are rarely updatedcan 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. Changes made to the semistatic tables can be transported to each workstation by using replication (covered briefly in this chapter, and in significant detail in

Alison Balter's Mastering Access 2002 Enterprise Development ).

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

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 2000 or Windows 2003 machine runs the Windows 2000 or 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 2000 or 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.

The Basics of Linking to External Data

Chapter 19, "Using External Data," covers linking to external data, including data not stored in another Access database. Three options are available to you:

• Design the databases separately from the start.

• Include all objects in one database, then split them manually when you're ready to distribute your application.

• Include all objects in one database, then split them by using the Database Splitter Wizard.

Chapter 19 covers the first two options. The last option, the Database Splitter Wizard, is covered here. To split the objects in a database into two separate .MDB files, follow these steps: