Why Use Database Replication?

Database replication is the process of copying a database so that two or more copies can exchange updates of data or replicated objects. This exchange is called synchronization. Each copy of the database is called a replica, and each contains a common set of tables, queries, forms, reports, macros, and modules. Each replica can also contain local objects that exist only in that specific replica.

Each replica is part of a replica set, which contains the Design Master and the other replicas for a database. The Design Master is the only replica where you can make changes to the database’s design and objects. Replicas that belong to the same replica set can synchronize with one another.

With database replication, you can:

• Share data among offices You can use database replication to create copies of a corporate database to send to each satellite office. Each location enters data into its replica, and all remote replicas are synchronized with the replica at corporate headquarters. An individual replica can maintain local tables that contain information not included in the other replicas in the set.
• Share data among dispersed users New information that is entered into the database while sales representatives are out of the office can be synchronized anytime the sales representatives establish an electronic link with the corporate network. As part of their workday routine, sales representatives can dial into the network, synchronize the replica, and work on the most current version of the database. Because only the incremental changes are transmitted during synchronization, the time and expense of keeping up-to-date information are minimized. Using partial replicas, it’s also possible to synchronize only certain parts of the data.

  See Also   For more information on partial replicas, see “Replicating Part of a Database” later in this chapter.

• Make server data accessible If your application doesn’t need to have immediate updates to data, you can use database replication to reduce the network load on your primary server. Introducing a second server with its own copy of the database improves response time. You determine the schedule for synchronizing the replicas and you can adjust that schedule to meet the changing needs of your users. Replication requires less centralized administration of the database while offering greater access to centralized data.
• Distribute application updates When you replicate your application, you automatically replicate not only the data in your tables, but also your application’s objects. If you make changes to the design of the database, the changes are transmitted during the next synchronization exchange; you don’t have to distribute complete new versions of the software.
• Back up data At first glance, database replication may appear to be very similar to copying a database. However, while replication initially makes a complete copy of the database, thereafter it simply synchronizes that replica’s objects with the original objects at regular intervals. This copy can be used to back up data if the original database is destroyed. Furthermore, users at any replica can continue to access the database during the entire backup process.

Although database replication can solve many of the problems inherent in distributed database processing, it is important to recognize the situations in which replication is less than ideal. You may not want to use replication if:

• There are large numbers of record updates at multiple replicas Applications that require frequent updating of existing records in different replicas are likely to have more record conflicts than applications that simply insert new records into a database. Record conflicts occur when two changes are made to the same record by users at different locations. Applications with many record conflicts require more time for someone to manually resolve those conflicts.
• Data consistency is critical at all times Applications that rely on information being correct at all times, such as funds transfer, airline reservations, and the tracking of package shipments, usually use a transaction method. While transactions can be processed within a replica, there is no support for processing transactions across replicas. The information exchanged between replicas during synchronization is the result of the transaction, not the transaction itself.

The new approach and flexibility that database replication offers can be illustrated by the development of a simple application. Imagine that a client has asked you to develop a contact management application for the company’s field sales staff to use to monitor sales and orders. Each sales representative has a laptop computer that can be connected to the company’s network.

One approach to building this application is to separate the tables from the other objects in the database. The data resides in tables in a back-end database on a network server while the queries, forms, reports, macros, and modules reside in a front-end database on each sales representative’s computer. When sales representatives want to retrieve or update data, they open and use the front-end database. Because the objects in the front-end database are based on linked tables, changes that sales representatives make to the data using these objects change the data in the back-end database.

See Also   For more information on this approach, see “Separating Your Application’s Tables from Its Other Objects” in Chapter 15, “Delivering Your Application.”

A better way to build this application is to use database replication to create a single database that contains both the data and objects, and then make replicas of the database for each sales representative.

You begin developing the application by creating a Microsoft Access database as you would for any application. Then you convert that database to a Design Master and make replicas on each user’s computer. Sales representatives update data in the replicas on their computers during the course of a work session, while you synchronize their replicas with the Design Master replica on the server as needed. You can also create a set of custom forms or reports that are used at only one replica location. The following sections discuss the tools you can use to implement each of these features.