When you convert a database to a Design Master, Microsoft Jet:
Microsoft Jet uses these changes to track modifications to your database’s design and data and to efficiently synchronize your database with other replicas in the replica set.
Important The addition of three new fields to your tables adds to the size of each record, and the addition of new system tables adds to the size of your database. Many of these new tables contain only a few records, but some of the new tables can grow significantly depending upon the frequency of synchronization between replicas. To reclaim unused space, compact your database frequently. For more information, see “Compacting a Replicated Database” later in this chapter.
When you convert a database to a Design Master, Microsoft Jet first looks at the existing fields in a table to determine if any field uses both the AutoNumber data type and the Replication ID field size. The Replication ID AutoNumber is a 16-byte value that appears in the following format:
{1234AB87-2314-7623-0000012340506801}
If no field uses that data type and field size, Microsoft Jet adds the s_GUID field to the table. The s_GUID field stores the Replication ID AutoNumber value that uniquely identifies each record. The Replication ID AutoNumber value for a specific record is identical across all replicas.
During the conversion process, Microsoft Jet also adds fields called s_Lineage and s_Generation to each table in the database. The s_Lineage field contains the value of the ReplicaID property of replicas that have updated a record and the last version created by each of those replicas. The s_Generation field stores information about groups of changes. Microsoft Jet also adds a field for every Memo and OLE Object field in a table.
Note The s_GUID, s_Lineage, and s_Generation system fields may or may not be visible, depending on whether the System Objects check box on the View tab of the Options dialog box (Tools menu) is selected or cleared.
Generally, there is a single field per record that stores information about changes. However, to optimize synchronizations for databases that contain Memo or OLE Object fields (sometimes referred to as a BLOBs, or binary large objects), an extra field is associated with each BLOB. If the BLOB is modified, this field value is set to 0 so that the BLOB is sent during the next synchronization. If other fields in the record are modified, but not the BLOB, the field value isn’t set to 0 and the BLOB isn’t sent.
This extra field is named Gen_FieldName, where FieldName is the BLOB field’s name (truncated, if necessary). One of these fields is set for each BLOB field.
See Also For more information on the s_GUID, s_Lineage, s_Generation, and Gen_FieldName fields, search the Help index for the name of the field.
When you convert a database to a Design Master, Microsoft Jet adds several new tables to the database. Most of these tables are system tables, which are not normally visible to users and cannot be manipulated by developers. The following table describes a few of the tables that are of the most interest to you as a developer.
| Name | Description |
| MSysSidetables | Identifies the names of tables that experienced a conflict and the name of the table that contains the conflicting records. MSysSidetables is visible only if a conflict has occurred between the user’s replica and another replica in the set. |
| MSysErrors | Identifies where and why errors occurred during data synchronization. |
| MSysSchemaProb | Identifies errors that occurred while synchronizing the design of the replica. This table is visible only if a design conflict has occurred between the user’s replica and another replica in the set. |
| MSysExchangeLog | Stores information about synchronizations that have taken place between replicas. |
To view these four tables (and the other system tables), select the System Objects check box on the View tab of the Options dialog box (Tools menu).
See Also For more information on these tables, search the Help index for the name of the table.
When you convert a database to a Design Master, Microsoft Jet adds new properties to it: ReplicaID, ReplicableBool, and DesignMasterID.
The ReplicaID property contains the value that uniquely identifies the replica or Design Master. Microsoft Jet automatically generates this value when you create a new replica.
During the conversion process, the ReplicableBool property is set to True, indicating that the database can now be replicated. Once this property is set to True, it cannot be changed. If you change the property setting to False (or to any value other than True), Microsoft Jet returns an error message.
You can use the DesignMasterID property to make another replica the Design Master. Set this property only in the current Design Master replica. Under extreme circumstances—for example, the loss of the original Design Master replica—you can set this property in the current replica. If you set this property in a replica when there is already another Design Master replica, you may prevent any further synchronization of data.
Caution Never create a second Design Master in a replica set. A second Design Master replica can result in the loss of data.
See Also For more information on these properties, search the Help index for the name of the property.
When you convert a database to a Design Master, the AutoNumber fields in your tables change from incremental to random numbering. All existing AutoNumber fields retain their values, but new values for inserted rows are random numbers. Random AutoNumber fields are not meaningful because they aren’t in any particular order and the highest value isn’t on the row inserted last. When you open a table with a random AutoNumber field as the primary key, the records appear in the order of ascending random numbers, not in insertion order. With random AutoNumber fields, it is possible for two different records to be assigned the same value, although the probability of this happening is very low. If this happens, updates could be made in incorrect records. To prevent such problems, consider using the s_GUID field as the primary key. Because all numbers in the s_GUID field are unique, each record has a different AutoNumber value.
Before you convert your database to a Design Master, determine if any of your applications or users rely on the order and incremental nature of the AutoNumber field. If so, you can use an additional Date/Time field to provide sequential ordering information.