| Bug-ID-Nummer |
BUG-000137415 |
| Eingereicht | February 11, 2021 |
| Zuletzt geändert | June 5, 2024 |
| Gilt für | ArcSDE/Enterprise Geodatabase |
| Gefunden in Version | 10.7.1 |
| Betriebssystem | Windows OS |
| Betriebssystemversion | N/A |
| Status | Will Not Be Addressed
Das Entwicklungsteam hat das Problem bzw. die Anforderung sorgfältig geprüft und ist zu dem Schluss gekommen, es nicht zu beheben bzw. keine weiteren Schritte zu unternehmen. Weitere Erläuterungen finden Sie ggf. im Abschnitt "Zusätzliche Informationen" des jeweiligen Problems.
|
Zusätzliche Informationen
The behavior comes down to a data modeling problem. The problem is there are "chained" relationships based on the same field being both foreign and primary keys.
Although the geodatabase may allow certain edits to these types of relationships, geodatabase replication is more strict. Where there is a dangling foreign key, nullify it. One reason for this is to avoid the dangling records being inadvertently related to a different record if at a later point in time an original record is created with that key value.
The recommendation is for "chained" relationships to be based on different key fields for each relationship class (do not have the same field used for all the relationships). If the relationships cannot be changed accordingly, then update the data to ensure values for all the related records in the chain before the sync.
The particular feature class, in this case, had 7 relationships – 5 with origin keys and 2 with foreign keys (one foreign key based in the field being edited and the other was based on another field – the latter is the recommended way to establish these relationships).
Workaround
Unregistering the relationship class (Strc_CFR_DSSPinsToCRPins) where DepProjNo is the foreign key from the replica resolves the issue.
Schritte zur Reproduzierung