topic Re: Workflow for gdb replication in ArcGIS Enterprise Questions

Workflow for gdb replication

mpboyle — Thu, 21 Jan 2016 16:09:17 GMT

This is my first go around with gdb replication and am looking to create a 1-way replica from a sde gdb to either another sde gdb or a file gdb. I was hoping to get an idea of the best practices and workflows for keeping the two gdbs in sync?

My assumption is you start with the Create Replica tool in order to replica data from parent to child, is that right?

After that is done, I have a few questions about workflow and best practices...

1) How do you add a feature class to the child gdb after the replication process is in effect?

2) If a feature class is deleted from the parent gdb, how do you delete the feature class in the child?...do you simply delete it through ArcCatalog?

3) If a field is added or removed in a feature class within the parent gdb, how do you send that change to the child gdb?...can it be automated or is it manual?

4) If a domain is added / altered / removed, how do you send those changes to the child?...can it be automated or is it manual?

5) What is a good 'routing' for syncing changes? Do you first reconcile and post edits in the parent gdb, then sync changes? Should some processes, like comparing schema be done first before syncing changes?

I'm looking to get an idea of what workflows others use that have been successful, easy to manage, and keeps your data in sync.

Thanks!

Re: Workflow for gdb replication

JacobBoyle — Thu, 21 Jan 2016 16:27:51 GMT

The Create Replica Tool is what I use.

Answers for questions 1-5:

you'll have to recreate the replica on the child
you can use the Export Replica Schema -> Compare Replica Schema -> Import Replica Changes tools
Same step as above, this is a manual process.
Same step as #2.
The Compare Replica Schema tool is only for making changes to the child database. If you are using a one-way replica, you'd only be pushing changes from the parent to the child, not the other way around. if you want to push and pull data from the child, then you need to use a 2 way replica

Re: Workflow for gdb replication

mpboyle — Thu, 21 Jan 2016 16:34:31 GMT

Jacob Boyle,

Thanks for the responses, that does help!

Say I wanted to script a routine to run daily, or on a regular interval to sync the parent gdb with the child gdb in a 1-way replica scenario. Would the steps below be realistic...?...or is there a 'better' or more realistic approach?

1) Reconcile and post edits in parent sde gdb to DEFAULT version

2) Export Replica Schema -> Compare Replica Schema -> Import Replica Changes --- this would be to keep schemas the same between the two gdb

3) Synchronize Changes

Re: Workflow for gdb replication

JacobBoyle — Fri, 22 Jan 2016 13:50:27 GMT

You could do that, but unless you're changing schema daily/weekly I'd just do it manually when you made changes. No reason IMO to add that overhead to your nightly syncs.

I'd just reconcile and post to Default and Synchronize Changes daily.

Re: Workflow for gdb replication

mpboyle — Fri, 22 Jan 2016 14:09:08 GMT

Jacob Boyle

If schema were to change, do you need to delete / unregister the replica and then re-create it? I guess I'm wondering when that is necessary? Would adding a feature class or field in the production sde gdb be brought over by running the export schema -> compare schemas -> import schemas?

Re: Workflow for gdb replication

JacobBoyle — Fri, 22 Jan 2016 15:42:23 GMT

If you change the existing schema, IE add a field, change a domain, delete a field, you can use export schema -> compare schema -> import schema.

If you're adding Feature Class, you'll need to re-create the replica.

Re: Workflow for gdb replication

mpboyle — Fri, 22 Jan 2016 15:52:10 GMT

Jacob Boyle,

Can replicas be overwritten or do they need to be unregistered from both gdbs?

Thanks for help!!!

Re: Workflow for gdb replication

JacobBoyle — Fri, 22 Jan 2016 17:21:02 GMT

You need to unregister the replica from both GDB, then delete the data from the Child. then you can re-create the replica.

Re: Workflow for gdb replication

mpboyle — Fri, 22 Jan 2016 17:40:13 GMT

Jacob Boyle,

I have a testing environment with an editing sde gdb and a child file gdb. The process seems pretty straight-forward for syncing changes, and updating schemas. However, I removed a field from a feature class in my editing gdb and the field still remains in the child gdb after running the export->compare->import schema tools.

I also added a domain and assigned the domain in the production gdb. The domain schema change is reflected in the child gdb. I'm wondering why the field that was removed in the editing fc still remains in the child fc? Does removing a field have to be done manually?

Re: Workflow for gdb replication

JacobBoyle — Fri, 22 Jan 2016 17:57:39 GMT

No, it should of deleted the field, make sure you use the resultant .xml from the compare tool when you import the schema changes, not the original .xml you exported.

That tool should add and delete fields, make changes to domains: Schema changes—ArcGIS Help | ArcGIS for Desktop

Re: Workflow for gdb replication

mpboyle — Sat, 11 Dec 2021 15:16:00 GMT

Jacob Boyle,

I'm using the .xml file produced after comparing the schemas. I just added a field in my editing gdb and it is added to the child gdb after running my script. Below is a skeleton of the python code I'm using...

import arcpy
import datetime
import os

def compare_replica_schemas(gdb_1, gdb_2, replica_name, output_file_folder):
    # gdb 1 is editing gdb
    # gdb 2 is child gdb
    run_time = datetime.datetime.now().strftime('%Y-%m-%d_%H-%M-%S')  # used for creating unique file name
    schema_file_parent = os.path.join(output_file_folder, run_time + '_schemaParent.xml')
    schema_file_compare = os.path.join(output_file_folder, run_time + '_schemaCompare.xml')
    # export schema from editing gdb
    arcpy.ExportReplicaSchema_management(gdb_1, schema_file_parent, replica_name)
    # compare replica schemas
    arcpy.CompareReplicaSchema_management(gdb_2, schema_file_parent, schema_file_compare)
    # import replica schema to child gdb
    arcpy.ImportReplicaSchema_management(gdb_2, schema_file_compare)

Re: Workflow for gdb replication

JacobBoyle — Fri, 22 Jan 2016 19:08:19 GMT

The Python looks right, logically. What happens if you do it manually? same result of the field not being deleted?

Re: Workflow for gdb replication

mpboyle — Fri, 22 Jan 2016 19:29:31 GMT

Nope...field (Field2) still exists.

Child gdb is on left, editing gdb is on right.

Re: Workflow for gdb replication

mpboyle — Fri, 22 Jan 2016 20:12:19 GMT

Jacob Boyle

When I right-click on the child gdb, go to Distributed Geodatabase, and Import Schema Changes...I am presented with a wizard that gives the option to confirm the deletion of 'Field2'. It is unchecked by default, which is what I'm guessing is being done through scripting...the field not being confirmed for deletion. I only get this wizard when doing the workflow I describe. If I use python or even the tools from the toolbox, I'm not presented with this.

This seems very annoying when trying to automate a process that would be run during off hours when users are not connected to a gdb and have locks established. I'm wondering why adding a field doesn't get the same result; it is added through scripting, while deleting a field is not removed through scripting.

Re: Workflow for gdb replication

ChrisDonohue__GISP — Fri, 22 Jan 2016 23:50:29 GMT

Adding some ESRI folks to the mix so they get a notification in case they have insights to add:

Jake Skinner

Vince Angelo

Asrujit SenGupta

Chris Donohue, GISP

Re: Workflow for gdb replication

JacobBoyle — Mon, 25 Jan 2016 15:26:53 GMT

check the ArcPy documentation for a parameter to set that value to true, I'd bet it's there. If not, maybe someone from the GDB team that's been added can chime in.

Like I said previously, we've found that the manual process was all we've needed, so i'm not familiar with scripting this process.

Re: Workflow for gdb replication

BenDrury — Wed, 03 Feb 2016 19:54:43 GMT

I was hoping to fine a more convenient answer to this question. We are always having some department wanting to add a feature class or delete on form here. I was hoping for some other way to do this and not break the replication, but looks as if there is no other way. Thanks for the information posted in this thread.

Re: Workflow for gdb replication

George_Thompson — Tue, 09 Feb 2016 15:07:52 GMT

Here is a blog that gives detailed information GDB replication and schema changes:

Simplify Your Life: Working with Schema Changes in Replicas | Support Services Blog

Geodatabase

Re: Workflow for gdb replication

Brownschuh — Wed, 06 Jun 2018 12:21:05 GMT

Matthew, stumbled upon this same issue you are experiencing yesterday. Check out this thread; same scenario ...