Changes made to your database when you use replication

When you replicate a Microsoft Access database, a number of changes are automatically made to your database.

Fields that are added to your tables when you replicate a database

When you replicate a database, Microsoft Access adds the following system fields to each replicated table in the replicated database:

Field	Description
s_GUID	A globally unique identifier for each record.
s_Lineage	A binary field that contains information about the history of changes to each record.
s_Generation	A field that stores information regarding groups of changes.

Notes

The s_GUID, s_Lineage, and s_Generation system fields are system objects that may or may not be visible in your tables. To make these fields visible in replicated tables, click Options on the Tools menu, click the View tab, and then select the System Objects check box. To see the fields, open a replicated table.
Additional fields (named Gen_Fieldname) are added for every Memo data type or OLE Object data type field in a table.
You can't change the information stored in the system fields in a replicated table.

Tables that are added to your database when you replicate it

When a Microsoft Access database is replicated and certain conditions occur, new system tables may be added to the database. Of these, the following new system tables may be of interest:

Table	Description
MSysSidetables	This table exists only if a conflict has occurred between the user's replica and another replica in the replica set. This table isn't replicated. It's supplied for information only, and its contents can be modified or deleted by custom conflict-resolution routines or by the user. All side tables are named table_conflict, where table is the original name of the table.
MSysSchemaProb	This table is present only when an error has occurred while updating the design of a replica. It provides additional details about the cause of the error. This is a local table and isn't replicated.
MSysReplicas	This table stores details, such as Replica ID and path, of all known replicas in the replica set. This table appears in all members of the replica set, but it is not replicated.
MSysTransAddress	This table stores addressing information for the Synchronizer and defines the set of synchronizers known to this replica set. This replicated table appears in all members of the replica set.
MSysTombstone	This table stores information about deleted records, and allows deletions to be dispersed to other replicas during the synchronization process. This table appears in all members of the replica set, but it is not a replicated table.
MSysRepInfo	This table stores information about the entire replica set, including the identity (GUID) of the Design Master. The table contains a single record. This replicated table appears in all members of the replica set.
MSysExchangeLog	This table stores information about replica synchronizations that have taken place. This is a local table and isn't replicated.

Notes

These tables are visible when system objects are visible.
You can't change the information stored in the MSysSchemaProb, MSysExchangeLog, MSysReplicas, MSysTransAddress, MSysTombstone, or MSysRepInfo system tables in a replicated database.

Properties that are added to your database when you replicate it

When you replicate a database or specify a database object as local, the following new properties may be added to the Properties collection of objects:

Property	Description
Replicable or ReplicableBool	A database or object property. When the property is set to T (or True for ReplicableBool), it indicates that the database or the table or query is now replicable. The Replicable and ReplicableBool properties may be used interchangeably.
KeepLocal	A property appended to a table or query. When the property is set to T, it indicates that the object should not be replicated when the database is replicated. An object that is already replicated can't have its KeepLocal property set to T.
ReplicaID	A property that provides each member of the replica set with unique identification. This property is read-only and is stored in the MSysReplicas system table.
DesignMasterID	The ReplicaID of the Design Master. It is stored in the MSysRepInfo system table as SchemaMaster.
ColumnLevelTracking	A database or table property. When the property is set to True (default), it indicates that conflicts are tracked at the column level of a table.
Replication ConflictFunction	The property is used to replace the Microsoft Access Conflict Viewer with a customized procedure that assists users in resolving synchronization conflicts.

Notes

Microsoft Access objects (forms, reports, macros, and modules) are either all replicated or are all local. Therefore, the Replicable and KeepLocal properties apply only to tables and queries.
To learn about the Replicable, KeepLocal, ReplicaID, and DesignMasterID properties, open the Visual Basic Editor and then open Visual Basic Editor Help.

Changes to the behavior of AutoNumber fields when you replicate a database

When you replicate a database, any incremental AutoNumber fields in your tables change to random numbering. All AutoNumber fields in existing records retain their values, but AutoNumber values for inserted records are random. In other words, the record numbers don't reflect the order in which the records were inserted and, consequently, the record inserted last doesn't necessarily have the highest value.

Before you replicate a database, determine whether any of your applications or users rely on an AutoNumber field's incremental numbering. If so, you can use an additional Date/Time field to provide sequential ordering information.

Note Replicas in an Access database that were created from a Microsoft SQL Server publication retain the AutoNumber functionality to support SQL Server's Named Range feature. You must manage these ranges in each replica.

Additional size limitations on a replicated database

The addition of three fields (s_GUID, s_Lineage, and s_Generation) imposes two limitations on your replicated tables:

The Microsoft Jet database engine allows a maximum of 2,048 bytes (not counting Memo or OLE Object fields) in a record. Replication uses a minimum of 54 bytes to store unique identifiers, indexes, and information about changes to the record. If the record contains either Memo or OLE Object fields, replication uses an additional 4 bytes for each of those fields. The total number of bytes available in a record in a replicated table can be calculated as follows:
2,048 bytes
- 54 bytes for replication overhead
- (4 bytes * the number of Memo fields)
- (4 bytes * the number of OLE Object fields)
= the maximum number of bytes available
The Microsoft Jet database engine allows a maximum of 255 fields in a table. Besides the three additional system fields, replication adds an extra field for each Memo and OLE Object field. The total number of fields available in a replicated table can be calculated as follows:
255 fields
- 3 system fields
- the number of Memo and OLE Object fields
= the number of fields available

Few well-designed applications use all the available fields in a table or all the bytes in a record. However, if you have a large number of Memo or OLE Object fields in your table, you might run into constraints.

Note In addition to setting limits on the available number of characters and fields, the Microsoft Jet database engine also limits the number of nested transactions allowed. You can have a maximum of seven nested transactions in a nonreplicated database, but a replicated database can have a maximum of six nested transactions.

The addition of several new system tables also adds to the size of your database. Most 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.

The size of your database file is significant for two reasons:

The Microsoft Jet database engine supports files up to a maximum of 1 gigabyte in size, but many users have limited space available on their hard disks. A replicated database that is larger than the original database file might use up a significant portion of the available disk space.
If you choose to make a backup copy of the nonreplicable form of your database, you must have sufficient space on your hard disk for both the replicated database and the backup copy.