One-way, child-to-parent replication compared to one-way, parent-to-child replication

Question

I came across the following line in the 9.4/10 documentation:  One-way replication allows data changes to be sent multiple times from the parent replica to the child replica and, starting at ArcGIS 9.4, from the child replica to the parent replica.

I am trying to sort out how this "new" functionality is more than just a matter of semantics, i.e., swapping what is called a parent and what is called a child. I would appreciate any feedback on how this new functionality is different from simply having an enterprise ArcSDE instance do one-way replication from a field-level ArcSDE instance. The only thing I have come up with is who drives the synchronization, the child or parent.

JoshuaBixby · Answer

garym, thanks.  Your response clarifies this "new" functionality for me.  When I posed the question, I understood the concept of one-way, child-to-parent replication, but the documentation made it sound like it was entirely new conceptually.  I was aware of the technical article you referenced; in fact, that article was part of what motivated the question.

I agree, there is a certain ease of use that comes with a conceptual functionality being integrated into a core product rather than implemented through a nuanced procedure.

GaryMacDougall · Answer

1 way replication prior to 10 was designed to send changes from a source to multple targets. For example, I have base data in the office and I want each field laptop to have a copy and be able to get updates from the office as changes happen. The new 1 way child to parent replication at 10 is designed to collect information from many sources. For example, data is managed in the county offices but I want to create a state wide office that encapsulates all the data from the counties. As part of setting this up, you can use 1 way child to parent replication to keep the state database up to date.

It was possible to set this up pre-10. See:

http://support.esri.com/index.cfm?fa=knowledgebase.techarticles.articleShow&d=34200

But having this option as part of the core product makes it easier to set up and more intuitive.

thanks
Gary

CherylCleghorn · Answer

This new approach allows for the parent dataset to be the same for all the replicas and the child replicas to all send their changes to the same datasets. This is useful for a central enterprise geodatabase having the edits done by each 'field' office for their geographic district, with central serving as the enterprise data repository.
With replication many replicas can be created from the same source data but a child geodatabase hosting many replicas must have distinct datasets.

In the 9.4/10 documentation section titled Replicas and geodatabases, note 2 important statements:
1) The source must be an ArcSDE geodatabase, and therefore, parent replicas can only be hosted by ArcSDE geodatabases. You can also create multiple replicas from a single-source geodatabase. For example, you can create a replica for each county from your statewide enterprise geodatabase. The data involved in each replica may also overlap. 
2) It is also possible for a single ArcSDE geodatabase to host multiple child replicas. In this case, however, the datasets involved in each child replica must be distinct. For example, if a feature class named parcels is involved in one child replica, it cannot be involved in any other child replica in that geodatabase.