Although Microsoft Jet makes database replication easy to implement through DAO programming or through Microsoft Access in combination with Microsoft Replication Manager and Briefcase, replication can be complicated by a number of special considerations. These considerations include:
This section presents these additional factors that must be included in your planning, design, and implementation of database replication.
The Design Master is the most important member of a replica set because it is the only member in which you can make changes to the structure of the database. Under certain circumstances, you might have to transfer the Design Master status to a replica. For example, you might have the Design Master on your computer while another member of your development team has a replica on his or her computer. While you are on vacation, you want the other programmer to be able to make changes to the database. You can use the DesignMasterID property to accomplish the transfer and synchronize the old and new Design Masters, as shown in the following code:
Sub SetNewDesignMaster(strOldDM As String, strNewDM As String) Dim dbsOldDM As Database, dbsNewDM As Database ' Open current Design Master in exclusive mode. Set dbsOldDM = OpenDatabase(strOldDM, True) ' Open database that will become the new Design Master. Set dbsNewDM = OpenDatabase(strNewDM, True) dbsOldDM.DesignMasterID = dbsNewDM.ReplicaID dbsOldDM.Synchronize strNewDM, dbRepImpExpChanges dbsOldDM.Close dbsNewDM.Close End Sub
You must have the Design Master open in order to make another replica the new Design Master. The Design Master is, by definition, read-write. If you make a replica that is designated read-only into the Design Master, the target replica is made read-write; the old Design Master also remains read-write.
If the Design Master is erased or corrupted, you can designate a replica to become the new Design Master. However, remember that you can have only one Design Master at a time.
If you decide to make your own replica the new Design Master for the set, synchronize it with all the replicas in the replica set before setting the DesignMasterID property in your replica. You must have your replica open in exclusive mode to make it the Design Master.
Caution Avoid using Windows or MS-DOS to copy or move replicas because using them will modify the internal information of the replicas. Moving a Design Master with Windows or MS-DOS will cause the Design Master to become a simple replica and may result in the loss of the record of conflicts associated with the replica, if any. If you are using Microsoft Replication Manager, you can use the Move Replica command on the File menu to move a replica or Design Master to another location.
Each time you change the design of your replicable database, Microsoft Jet stores information about the change in the MSysSchemaChg system table. If you change the same object more than once before synchronizing, Microsoft Jet continues to store the newest design in preparation for the synchronization. Frequent compacting of the database after you make design changes helps to reduce the overhead required for storing changes and reduces the information sent to the replicas. You might find it most efficient to compact your database daily and again just before synchronization.
Important Before compacting a replicated database, see “Important Considerations When Compacting Replicated Databases” in Chapter 13, “Optimizing Performance.”
When two members of a replica set are synchronized, Microsoft Jet applies the design changes to each member before applying the data changes. You can reduce the amount of processing during synchronization and reduce the potential for conflicts if you synchronize all the replicas in the set before making design changes to the Design Master.
Microsoft Jet must open tables exclusively before design changes are applied to them. If you are using a table in a database at the time you want to synchronize, Microsoft Jet suggests that you first close the table. If you use a “Synchronize Now” button on a form so users can easily click the button whenever they need to synchronize, be sure the button does not have an associated table open — either directly or through a query — in the database that is being synchronized.
If you tie list boxes to replicable tables, under certain circumstances the list box might display system fields in addition to your regular data fields. If the option to display system objects is turned on, the system fields in the replication system tables are also displayed. After they’re visible, they might appear in the related list box.
To avoid displaying system tables, either clear the System Objects check box on the View tab of the Microsoft Access Options dialog box (Tools menu), or base the list box on a query that selects only the fields you want displayed.
You can distribute your Microsoft Access database application to others by including Replication Manager. Setting up replicated databases with Replication Manager is a cooperative effort involving the programmer and the site administrator. To prepare your database for replication and distribution, you need information from the site administrator, and you need to assist the administrator — preferably in person at the customer’s site.
The recommended topology for using Replication Manager with your application is a star topology, shown in Figure 7.4. You should place the Design Master on a satellite computer along with Replication Manager, but you should not have it on a synchronization schedule. (You, or the administrator at the site, can synchronize it with the hub replica when a structural change to the database is needed.) The replica on the hub becomes the synchronization partner for each of the other replicas in the organization. In addition to the Design Master and the hub replica, a base replica is used with the Setup program to copy subsequent replicas to users’ machines. After a copy is made on a user’s computer and it is synchronized with the hub, the copy becomes a true replica with its own unique identification.
Figure 7.4 Star topology for distributing your application
See Also For more information about distributing your applications with Replication Manager, see “Distributing Replicated Databases” in the Microsoft Replication Manager Help file.
After you’ve converted a database into a replicable database, you can’t convert it back to its former status as a nonreplicable database. However, if you no longer want to use replication and want to decrease the size of a replicated database, you can create a new, nonreplicable database that contains all of the objects and data in your replicated database without the additional system fields, tables, and properties associated with replication.
Note The Replica to Regular Database Wizard, which is located in the ReplWizard folder on the companion CD-ROM, enables you to convert a Design Master to its original, nonreplicated state.
Û To make a nonreplicable database from a replicable one by using Microsoft Access
Important If the s_GUID field is a primary key (and foreign keys in other tables refer to it), you’ll want the s_GUID field in the new table. If the s_GUID field is not used as a primary key, there is no reason to preserve it in the new table. The s_Lineage and s_Generation fields should not be copied over to the new table.
To create the queries, open query Design view, and click Make-Table Query on the Query menu. In the Table Name box, select the current table. Click Another Database, and add the name of the database that you created in step 1. Run the query.