Problem: Edits to relationships, where the objectid is the primary key, may be incorrectly synchronized with two-way and one-way replication
The primary key for a relationship may be based on a geodatabase maintained GlobalID, an application or customer maintained primary key, or a geodatabase maintained objectid.
In some use cases, edits involving relationships may be incorrectly synchronized when the primary key for the relationship is based on an objectid (OID) column.
The following is an example use case where edits are incorrectly synchronized:
Consider an example where there is a poles feature class and a transformers table in a two-way replica. In this example, there is a simple relationship class between the poles and transformers. Poles is the origin class and the primary key is its objectid column. Transformers is the destination class and the foreign key is a long integer column called poleid.
The following describes a use case where relationships are not correctly synchronized:
1) A new pole (objectid = 10) is added to the parent replica geodatabase.
2) A new transformer (objectid = 100) is added to the parent replica.
3) The replica is then synchronized from parent to child, which adds the new pole and transformer to the child replica. The objectid assigned to the new pole in the child replica is 12. This is because objectid 10 is already used by another feature in the child replica. The objectid assigned to the new transformer is 105. The globalids for these rows are identical to the corresponding values in the parent geodatabase, and are what is used to maintain the subsequent correspondence between features.
4) In the parent, a new relationship is added between the parcel with objectid 10 and the transformer with objectid 100. This sets the embedded poleid value (foreign key) in the transformer row to 10.
5) The replica is synchronized again from parent to child. The change to the transformer row in the parent is applied to the transformer row in the child geodatabase with objectid 105 (using the globalids to establish correspondence). However, the updated value of the poleid in the child transformer row is incorrect. It is updated to 10, but it should have been 12.
The following is an example use case where edits are correctly synchronized:
The example described above would work correctly if the edit to create the relationship between the pole and the transformer had been made in the same generation of edits in which the pole and transformer were originally created. For instance, if the relationship had been created before the synchronization in step 3. The synchronization algorithm records the change in the objectid of the pole on creation, and uses it to update the foreign key in the transformer correctly.
Notes on use cases where edits are correctly synchronized:
The use cases where edits are correctly synchronized correspond to common workflows with feature-linked annotation, which is based on objectid as a primary key. The most common workflow involves creating a feature together with its linked annotation as part of the same edit session. Once an annotation is created for a feature, its relationship with that feature is not changed in subsequent edits. Not all workflows involving feature linked annotation are supported. For example, creating a new piece of related annotation for a feature in a generation that does not involve the creation of the feature is not supported. The workflows that are supported rely on ArcGIS 9.2 Service Pack 5.
In some use cases (see the Description section above), edits involving relationships may be incorrectly synchronized with two-way and one-way replication when the primary key for the relationship is based on an objectid (OID) column.
Solution or Workaround
This issue has been addressed in ArcGIS 9.2 Service Pack 6 and ArcGIS 9.3. An additional case has also been addressed in the following ArcGIS 9.2 Service Pack 6 patch as well as ArcGIS 9.3 Service Pack 1.
Also, this problem is not encountered when editing and synchronizing relationships with two-way and one-way replicas using GlobalID columns or customer-defined primary keys, such as EquipmentID, that are unique across all databases, as the primary keys in the relationship.
In the example above where edits are incorrectly synchronized, the relationship class could have been defined with the globalid column from poles as the primary key and a guid column from transformers as the foreign key. Relationship classes that use a globalid as the primary key require a guid column as the foreign key. In this use case, the relationship would have been properly synchronized since the globalid and guid values are the same across the replicas.