Show Navigation | Hide Navigation
You are here:
Geodatabases and ArcSDE > Data management workflows, transactions, and versioning > Managing Distributed Data

Replicating related data(ArcInfo and ArcEditor only)

Release 9.3
Last modified April 2, 2009
E-mail This Topic Printable Version Give Us Feedback

Print all topics in : "Managing Distributed Data"

Related Topics

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.

Each relationship class is processed in only one direction. By default the direction is forward, but this can also be changed to backward at creation time. A forward direction means that the origin class is evaluated to add related rows from the destination class to the replica. A backward direction means that the destination class is evaluated to add related rows from the origin class to the replica. It is also possible to turn off relationship class processing for a specific relationship class during replica creation.

Since each dataset is evaluated once and each relationship class is processed in, at most, one direction, the order in which the datasets are evaluated is important. The system has logic to process the datasets in the order for which the most related objects will be added. You can affect the order in which datasets are processed by changing the direction or turning off processing for specific relationship classes.

The following examples will 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.

Examples of replicating related data

Relationship class data model

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 building and parcels to the replica.

Replicating related data

Example two

This example shows replicating relationships through forward processing. By selecting the two buldings in the parent replica for replication and using the default forward processing direction for related records, the annotation that is related to those buildings also gets replicated to the child.

Replicating related data

The next diagram shows a case where you choose those same two buildings but decide to use a backwards processing direction for the prop_build relationship class. Here, in addition to the related building annotation, the parcels related to those buildings as well as the parcels' annotation are included.

Replicating related data (backwards processing)

Example three

In the previous examples, a replica was made using the default behavior of including related objects. It is possible to override this behavior either at the global or local level to customize replication. At the global level, the replication process may be configured to not include any related objects associated with features identified for replication.

In this example, the buildings and properties are selected in the replica area, but since the option to exclude related records was chosen, the annotation associated with the buildings and parcels is not replicated.

Replicating excluding related records

Example four

In this example, although the replica area includes four properties (17691, 17692, 17698, and 17697) that have related buildings, all buildings have been explicitly excluded from replication. As the global default behavior to always include related objects is still in effect for the other feature classes, the property annotation will again be included in the replica.

Replicating data excluding specific datasets

Example five

This example shows what happens in the case of a circular relationship. During the replica creation process, the system applies some logic to break the circle to 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.

Replicating circular relationships

In order to get a predictable result in the case of circular relationships, you can choose to not process one of the relationships, or choose backward processing for one of the relationship classes. For example, the diagram below shows the case where R3 is set to process backwards. Now the order of processing is predictably T1–T2–T3. Here, T3 will have related records added from T1 and T2, but no records from T3 will be added to T1 or T2.

Replicating circular relationships

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. Good alternatives include these:

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 completely 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 you may see unexpected behavior:

Please visit the Feedback page to comment or give suggestions on ArcGIS Desktop Help.
Copyright © Environmental Systems Research Institute, Inc.