Child to parent replication

[PasiHyvonen]

Could someone confirm how the new one-way child to parent replication in 9.4 will work? (I haven't got 9.4 geodatabases setup yet for testing...)

Currently (pre 9.4) one-way child to parent replication works only for one child. Trying to register another child replica to same parent fails with error saying target already contains data. Workaround is to get copy of the all the child GDBs data to parent and then create replicas with 'register with existing data' option. Problem with that is copying data without changing globalIDs...

Will 9.4 make all this easier and simply allow me to create one-way replicas from multiple child GDBs to one parent GDB, without the hassle of copying data first?

Scenario I have is where 30 district geodatabases all maintain their own data (same schema, just data for different area). What I need is up-to-date copy of all districts data in the head office GDB for analysis and reporting. This new 9.4 one-way child to parent replication sounds like it could be the solution...

Thanks,
Pasi

[RussellBrennan]

Pasi,

When creating a replica at 9.4 you will have two options for the 'One way replica'. You can choose 'Parent to child' and 'Child to parent'. When choosing the 'Child to parent' option you will be able to copy data from the child geodatabase to the parent geodatabase manually and then use the 'register existing data' option.

If using the wizard to copy the data you will need to begin with the data existing on the parent. The wizard will then copy the data to the child (data sender). This is the same as creating a 'one way' parent to child with respect to copying the data.

This type of replication was set up with the workflow you describe in mind.

[GaryMacDougall]

If the data is already in the central GDB, then you can just create replicas as usual and use the new 1 way child to parent replica type. This will copy the data to the child and then allow the child to make up edits and sync to the parent. Once the replicas are created, the central GDB just receives changes.

If the data starts off in the child geodatabases, you first need to load the data into the central GDB and then create replica back to the children using the register only option. When you load the data into the central GDB, you need to preserve the globalids from the children. This article dscribes how:

http://resources.esri.com/help/9.3/ArcGISDesktop/dotnet/4EC15E04-CF70-47B4-A02C-E24AEAC3B981.htm

This workflow allows you to have one central GDB that contains all data from several child sources. You can use the central GDB to run analysis and print maps across all of the data.

[PasiHyvonen]

I can't really see what is new here in 9.4.

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

describes how you can setup one way child to parent replicas and it was already there for 9.0. What does 9.4 add to this?

I was hoping the new thing in 9.4 would be that there is no need to copy all data into the parent first. It is the moving of data with globalIDs that I would like to avoid. We have a set of 'orphan' child geodatabases without a parent. I would like a parent GDB simply to 'adopt' these child GDBs and accept data from them. The initial sync, or setting up the replication, would get all existing data from the child GDB tables and feature class into the parent.

Pasi

[SteveDuquette]

Hi There...

Sorry for the late responce...but just in case someone hits this page:

You can do that in 9.3.1 with this code:

http://resources.esri.com/help/9.3/ArcGISDesktop/dotnet/4EC15E04-CF70-47B4-A02C-E24AEAC3B981.htm

Of course when you do it like that your moving the data from one spot to the other...but you are preserving your Global IDs.

Then you create a replica using existing data....and your good to go from that point on!

Not perfect but might be a suitable solution for some...

Steve Duquette
Geospatial servers and applications specialist /
Spécialiste, serveurs et applications géospatiales
Stratégies et plans / Strategy and plans
Parcs Canada, Parks Canada

I can't really see what is new here in 9.4.

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

describes how you can setup one way child to parent replicas and it was already there for 9.0. What does 9.4 add to this?

I was hoping the new thing in 9.4 would be that there is no need to copy all data into the parent first. It is the moving of data with globalIDs that I would like to avoid. We have a set of 'orphan' child geodatabases without a parent. I would like a parent GDB simply to 'adopt' these child GDBs and accept data from them. The initial sync, or setting up the replication, would get all existing data from the child GDB tables and feature class into the parent.

Pasi

[MichaelMannion]

We have a set of 'orphan' child geodatabases without a parent. I would like a parent GDB simply to 'adopt' these child GDBs and accept data from them.
Pasi

We're in the same situation, and are looking for a simpler way to implement the aggregation scenario described in KB34200.

We currently have 10+ regional geodatabases that we'd like to consolidate via replication into one central database for publishing. We'd like to find a workflow that can be written down and followed by analysts whenever a new aggregation-type replica is required. Specifically, this workflow should:

1. Avoid the need for custom ArcObjects development

2. Preserve the existing regional data, without the need to delete and re-load it from the consolidated database

With respect to #1 above, it appears that it is currently necessary to use ArcObjects to load data from multiple feature classes (e.g. states) into a single consolidated feature class (e.g. nation) while preserving GlobalID values. This is based on information from the 'How to copy or load data and preserve GlobalID values' article (http://resources.esri.com/help/9.3/ArcGISDesktop/dotnet/4EC15E04-CF70-47B4-A02C-E24AEAC3B981.htm).

Using ArcObjects presents a configuration management, budget, and support issue. In short, we don't want to develop an ArcObjects-based solution for our client if we can achieve the same goal using Python scripting, or even just documented step-by-step instructions. Updating an ArcObjects-based tool for new software releases, to fix bugs, or to add functionality requires the client to have us, the contractor, do the work. Conversely, the client could take ownership of a Python tool or a standard operating procedure document on their own.

Regarding #2, per KB34200, the 9.2 method for configuring this aggregation type of replication does not require ArcObjects. It does, however, require deleting all data from the regional databases and replacing it with a new copy that has been split out of the aggregated database. Given the continual presence of outstanding editing versions in the regional databases, there is never a time when we can just wipe out the existing data. We need to keep the regional databases intact, and create the aggregated, central database from them.

With that as background, my question is:

Q: Is there any way to configure the replication scenario described in KB34200 without deleting data from the regional databases, and without using ArcObjects?

Thanks for any suggestions.

-Michael

[PasiHyvonen]

The solution we ended up using was to setup separate one-way parent to child replicas from the remote sde geodatabase into file geodatabase in the central office. So each one has its own parent, or target, FGDB. We then have a python script that combines the data from all those replica fgdbs into a central sde geodatabase.

That python that combines data isn't changes only, it simply reloads the data in sde from those fgdbs.Takes few hours to run but that is ok as a nightly task.

Advantage of that is it is very simple (the simplest possible replication scenario) and in case anything goes wrong with one replica we can just re-create that without affecting others.