SYNCHRONIZING REPLICAS

After you make a database replicable and create an additional replica, you want to synchronize the replicas so that updates are propagated.

The Synchronize method applies to a replicable database object. It exchanges schema and data with a target replica. This is always a “pair-wise” exchange between a source replica and a target replica, with an option to select the direction of changes from bidirectional, import only, or export only, and the exchange mode from indirect, Internet, or direct. This is the syntax:

rep.Synchronize Target,
						SyncType,
						SyncMode
					

The Synchronize method uses the following parameters:

• Target is a String value that specifies the path and filename of the replica with which to synchronize, the name of the synchronizer that manages the target replica, or the name of the Internet server that contains the target replica.

• SyncType is an optional Enum value that specifies the synchronization type to perform. The following values are valid for SyncType:

  jrSyncTypeExport	Sends changes from the current replica to the target replica
  jrSyncTypeImport	Sends changes from the target replica to the current replica
  jrSyncTypeImpExp (the default)	Sends changes from the current replica to the target replica and vice versa

  
  

• SyncMode is an optional Enum value specifying the method of synchronization. The following values are valid for SyncMode:

  jrSyncModeIndirect (the default)	Indirect synchronization
  jrSyncModeDirect	Direct synchronization
  jrSyncModeInternet	Indirect synchronization over the Internet

  
  

The code in Listing 23.4 takes the filenames and exchange type of the source and target replicas and does a direct exchange. You can find this code on the Sync Two Replicas form in the Chap23.mdb database (on the CD-ROM in the ExamplesChap23 folder). The code is attached to the cmdSyncReplicas command button.

Listing 23.4. Chap23.mdb: Performing a Direct Exchange

Private Sub cmdSynchronize_Click()

    Dim rep As New JRO.Replica
    Dim strSourceReplica As String
    Dim strTargetReplica As String
    Dim eExchangeType As SyncTypeEnum
    Dim lExchangeType As Long

    'Place error checking here to confirm existence of files and folders
    strSourceReplica = Me!txtSourceReplica
    strTargetReplica = Me!txtTargetReplica
    lExchangeType = Me!frExchangeType

    Select Case lExchangeType
        Case 1
            eExchangeType = jrSyncTypeImpExp
        Case 2
            eExchangeType = jrSyncTypeImport
        Case 3
            eExchangeType = jrSyncTypeExport
    End Select

    'Set ActiveConnection to the Source Replica
    rep.ActiveConnection = strSourceReplica

    'Synchronize the replicas
    rep.Synchronize strTargetReplica, eExchangeType, jrSyncModeDirect

    Set rep = Nothing

    MsgBox ("Synchronization of " & strSourceReplica & " and " & _
       strTargetReplica & " is complete.")

End Sub

Understanding the Design Master and Replicas

A replica set can contain only one Design Master, but it can contain as many replicas as needed. The Design Master is the only replica in which changes to the database design are allowed. You can designate any replica with global visibility as the Design Master. Make sure, however, that only one replica is marked as the Design Master at any time to prevent two replicas from making design changes that would be incompatible in the event of a synchronization. When a database is made replicable, properties are set that identify the database as the Design Master.

Let's investigate each attribute in a bit more detail to see why the Design Master is unique. As the following table shows, the Design Master or any replica can create a new replica. There are no restrictions within Access, nor can this be prevented by permissions. You can leave Access and create a DOS copy of the database, and thereby create a new replica, so any Access security would be easily avoided.

The Design Master or any non-ReadOnly replica can insert new records, update existing records, or delete records if the user has permission. Normal Access security is enforced, so if you want to restrict users, you can use the standard Access object/permission/user security. (See Chapter 21, “Securing Your Application,” for more information.)

The Design Master is the only database in the replica set permitted to create replicable objects. When a table or query is created in the Design Master, it's initially created as a local table or query (non-replicable). To make it global in the Access database container, right-click the object and check its Replicable property. Now when you synchronize with the other replicas in the set, the table or query will be propagated. Any single replica can also contain local tables or queries that exist only in that replica.

A new feature of Access 2000 affects the replicability of Access objects (forms, reports, Data Access Page links, macros, and modules). In Access 2000, all Access objects are stored in a single binary large object (BLOB) within the database file. Therefore, all Access objects are either replicable or local, which must be specified before making the database replicable. See the later section “Using Replicable and Non-Replicable Objects” for more information about the new Access project.

You can move the Design Master attribute to one of the replicas during a synchronization. If one of the databases in an exchange is the Design Master, the user can transfer the Design Master to the replica. You can also the use the JRO DesignMasterID property to move the Design Master property to another replica.

Recovering the Design Master

In case of a disaster (the Design Master is destroyed), you can promote one of the other replicas to become the Design Master for the replica set. To recover a Design Master for the replica set, from the Tools menu choose Replication and then choose Recover Design Master.

You can also choose these same menu options in Replication Manager. Also, through code you can set the JRO DesignMasterID property to allow a replica to become the Design Master.

Replication Visibilities

Access 2000's Microsoft Jet 4.0 replication defines three degrees of visibility for replicas. Visibility is a level of restriction and functionality a replica has in a replica set. A replica's visibility can be defined as global, local, or anonymous.

Global replicas have the same visibility as replicas created in Access 97/95 (Microsoft Jet 3.x). A global replica can synchronize with all other global replicas in the replica set. A global replica can also synchronize with any replica created from it, with some exceptions. The Design Master's visibility is always global. By default, any new replica created from a global replica is also a global replica. From a global replica, you can create a global, local, or anonymous replica.

Local replicas can synchronize only with their parent, a global replica, and aren't permitted to synchronize with other replicas in the replica set. This way, you can easily control a replica set's topology. For example, you can use local replicas to enforce a star topology at individual sites where you want to ensure that synchronization between sites goes through a global hub at each site. Other replicas in the replica set won't be aware of the local replica. The parent replica can schedule synchronizations with a local replica by using Replication Manager. The parent replica proxies any replication updates and conflicts for the local replica, meaning that all changes appear as though they came from the parent replica. Local replicas always have a priority of 0.

Anonymous replicas are important for the Internet scenario where you don't want to keep track of every replica's addition or synchronization in the replica set. An anonymous replica can synchronize only with its parent, a global replica. Anonymous replicas are similar to local replicas, except that anonymous replica information isn't permanently stored in the system tables. These replicas subscribe through the Internet and don't have any particular identity in the parent replica; instead, they proxy their identity for updates through the parent replica. By removing the information about the anonymous replica after a period of inactivity, the overall size of replicas in the replica set is reduced if many replicas in your set are anonymous replicas. It also helps to keep out unnecessary topology information about replicas that participate only occasionally. The parent replica, always a global replica, can't schedule synchronizations with an anonymous replica. Anonymous replicas always have a priority of 0.

Replication System Columns, Tables, and Other Mysteries

When a database is converted to a replicated database, it undergoes many changes. Many of these changes use the 128-bit GUID (Globally Unique Identifier) data type. Its primary advantage in a distributed, replicated database is that if two GUIDs are created at two separate, disconnected PCs, you can virtually guarantee that they'll be never be the same. For detailed information about replication system tables and columns, as well as how to implement replication, create replicas, synchronize data, resolve conflicts, and other topics, review the “Database Replication in Microsoft Jet 4.0” white paper available on the file RepJet40.doc, available on the accompanying CD-ROM in the ExamplesChap23 folder.

GUIDs are used anywhere a unique identifier is required and must be generated even when it's impossible to check the values already used at other replicas. A GUID individually identifies the following:

• Records in any replicated table (ReplicationID)

• Replicas (ReplicaID in the MSysReplicas system table)

• Replica sets (GlobalDbid in the MysRepInfo system table)

• Tables (s_GUID in the MSysTableGuids system table)

These GUID fields are usually hidden from view; to see them, choose Options from the Tools menu, click the View tab, and select System Objects. These system objects are protected from modification by users and developers.

Each record in every user table gains at least three new fields—four if ColumnLevelTracking is the default when it's made replicable. Figure 23.4 shows a replicated database with a single text field.

Whenever a new record is inserted, it's given a GUID in the s_GUID field, which is used as the unique key to distinguish this record from any other new records inserted at other replicas. The s_GUID field also is used as the unique key to identify conflicts when two replicas update the same record. Because a user can never modify the s_GUID field, it's always possible to track conflicts. (This wouldn't be possible if the user-defined primary key were the conflict identifier because it would be subject to potential change.)

The s_Generation field is a 4-byte-long integer used to optimize exchanges between replicas. Each time an exchange occurs at a replica, its generation counter is incremented.

s_Lineage is an OLE Object field of variable size—with a minimum of 4 bytes—used to resolve the winner in the event of a data conflict and to optimize the exchange of records between replicas.

s_ColLineage is an OLE Object field of variable size—with a minimum of 4 bytes—used to resolve the winner in case of a ColumnLevelTracked data conflict and to optimize the exchange of records between replicas. Thus, this field is added only if the table is ColumnLevelTracked.

The addition of these extra fields adds to the size of the database. The s_GUID and s_Generation fields are also indexed.

Additional system tables are also added to the database to keep track of replicas in the set, exchange histories, schema changes, deleted records, and other information internal to replication.

Using Replica Sets

All replicas derived from the conversion of the original database belong to the same replica set. This is very important because only replicas from the same set can exchange and synchronize with each other. The ramification is that replicas from different sets can never synchronize with each other. Each replica set is identified by a unique replica set ID.