The issue arises becauseOne-way, parent to child replicationis being used. In this type of replication, changes from the parent replica (production server) overwrite the data in the child replica (consultant's server) during synchronization, regardless of edits made in the child replica.
1. One-way Replication Workflow
Parent to Child: Changes are pushed from the parent to the child. The child can make local edits, but these edits are not sent back to the parent, and they can be overwritten when synchronizing.
In this case, the consultant's edits are overwritten because the synchronization is unidirectional from the production server to the consultant's server.
2. Issue with Conflicting Edits
SinceOne-way, parent to childreplication does not support bi-directional synchronization or conflict detection, local changes in the child replica are not preserved if the parent replica pushes updates that conflict with them.
3. Why Not Other Options?
Checkout/check-in:
This replication type allows edits to be made in the checkout replica and reconciled back to the parent during check-in. This ensures that conflicting edits are addressed.
One-way, child to parent:
In this replication, edits flow from the child replica to the parent replica. The issue described does not align with this setup.
References from Esri Documentation and Learning Resources:
Geodatabase Replication—ArcGIS Pro Documentation
Understanding One-Way Replication
Conclusion:
The issue occurs becauseOne-way, parent to child replicationis being used, where edits made on the child replica are overwritten by updates from the parent replica during synchronization.
