Available with Standard or Advanced license.
During replica creation, rows and features are added to a replica based on the filters defined in the application. Once this is completed, relationship classes are processed to include additional related objects.
Relationship class processing involves evaluating each dataset that participates in at least one relationship class. When a dataset is evaluated, all rows that have already been replicated are collected and used to query for related rows in the related datasets. Any related rows returned from the queries are added to the replica. Each dataset is visited once during this process.
Within ArcGIS Pro, a relationship class is always processed in only one direction, forward. A forward direction means that the origin class is evaluated to add related rows from the destination class to the replica. You can also turn off relationship class processing during replica creation.
The following examples illustrate the replication behavior with respect to related objects. The data model used in these examples is a simple origin-destination relationship between properties, buildings, and their related annotation.
Example one
This example shows the replica area covering eight parcels and six buildings. When the replica is created, two additional buildings are added, since they're related to the parcels. Relationship class processing also adds annotation for the buildings and parcels to the replica.
In this example above, a replica was made using the default behavior, which includes related objects. Within ArcGIS Pro, you can customize replication and override this behavior at the global level when using the Create Replica geoprocessing tool. At the global level, the replication process may be configured to not include any related objects associated with features identified for replication.
Example two
This example shows what happens in the case of a circular relationship. During the replica creation process, the system applies logic to break the circle and prevent it from processing in an endless loop. However, this logic makes it such that the order in which relationships are processed can't be predicted.
Relationship classes where an ObjectID field is the primary key field
Replicating with relationship classes where an ObjectID field is used as a primary key field requires additional processing during synchronization, which can affect performance. It can also result in unexpected behavior in some cases. The following describes these in more detail. After reviewing this section, you may decide to modify your relationship classes to use primary key fields other than the ObjectID field. The following are good alternatives to consider:
- Relationship classes with a primary key field of type GlobalID and a foreign key field of type GUID
- Create and use your own primary key field, which is unique across all databases
Additional processing during synchronization when the ObjectID field is the primary key field
The ObjectID values in a feature class or table are not unique across geodatabases. A new row in one replica geodatabase may be allocated the same ObjectID as a different row in the other replica geodatabase. The synchronization process must account for these differences when transferring relationships across replica geodatabases when the primary key in the relationship is an ObjectID column. To accomplish this, the synchronization process detects relationship classes that use the ObjectID column. If any such classes are present, the synchronization process transmits additional information that is then used to perform additional processing.
The processing involves adjusting foreign key values to target the appropriate ObjectID value in the target geodatabase for each edited relationship. In cases where a large number of relationships are edited, this additional processing may have a noticeable effect on synchronization performance.
Unexpected behavior when the ObjectID field is the primary key field
The following describes cases where unexpected behavior may be observed when the ObjectID field is used as the primary key field:
- Edits where the origin row does not exist in the target replica geodatabase—As described above, the synchronization process performs additional processing to maintain relationships when an ObjectID field is the primary key field in a relationship class. A relationship is not maintained, however, in cases where the edit involves referencing an origin row that does not exist in the relative replica geodatabase. For an insert, this results in the foreign key being set to null in the destination row. For an update, the foreign key value is left as it existed prior to the synchronization in the destination row. Note that this behavior does not occur with checkout/check-in replicas.
- The diagram above shows a case where a simple relationship class exists between parcels and buildings where the ObjectID field of the parcels feature class is the origin primary key. In this example, a replica is created for only the parcels and buildings within a spatial extent. After the replica is created, however, a digitizing error is detected where a building is found to have been digitized in the wrong parcel. This is corrected in the parent replica geodatabase by moving the building and editing the relationship such that it is related to the correct parcel. The replica is then synchronized to apply the changes to the child replica. In this case the building is moved, but it is still related to the incorrect parcel in the child replica. The relationship was not changed in the child replica because the correct origin row (parcel with ObjectID 102 in the parent replica) does not exist in the child replica geodatabases. In these cases, relationships are not altered.
- Dangling foreign keys—When creating a replica, rows are copied from the source geodatabase to the target geodatabase based on how the replica is defined. When defining the replica, you can choose to include rows from the destination table without the related rows in the origin table. The foreign key values in the destination table for these unrelated rows are the same as they are in the source geodatabase. These are dangling foreign keys, since the origin row they reference does not exist in the target geodatabase.
- The diagram above describes an example of where unexpected behavior can result from having dangling foreign keys. Here, the parent replica geodatabase has a simple relationship class between parcels and buildings. The parcel feature class is the origin and uses the ObjectID field as the primary key. A replica is created to include all buildings in the city and parcels for one city block. The replica creation process copies the appropriate parcels and buildings from the parent replica geodatabase to the child replica geodatabase. In the child replica, buildings related to parcels outside the city block have dangling foreign keys, since these parcels are not part of the replica. For example, the building with a foreign key of 100 has a dangling foreign key, since the parcel with ObjectID 100 does not exist in the child. If a new parcel is created in the child replica and is assigned an ObjectID of 100, it will be unintentionally related to the building.