Considerations for One-Way Replication Using Truncate/Append Update Method

4263
3
Jump to solution
01-15-2015 08:47 AM
Highlighted
Occasional Contributor III

We are currently looking at deployment scenarios for ArcGIS for Server. We are finding that having local copies of file geodatabases on GIS servers is ideal for building map caches and performance. ArcGIS Help documentation recommends using geodatabase replication for publishing local copies of data to GIS servers (especially when in a new projection (e.g., Web Mercator Auxiliary Sphere). In our production environment we have an editing ArcSDE geodatabase and a publish (read-only) ArcSDE database that receives updates via python scripts that first truncate the destination table in the publish geodatabase and then append features from the edit geodatabase to the truncated table. We follow this method to avoid deleting feature class metadata using the create/delete method of updating features.

I have a concern about using one-way replication in this scenario for local copies of file geodatabases on GIS servers. How will we be able to manage the GlobalID column when we are truncating and appending? The GlobalIDs will be different between the data source and data target of the one-way replica. What are some potential workarounds to this scenario?

Reply
0 Kudos
1 Solution

Accepted Solutions
Highlighted
MVP Esteemed Contributor

John-  I have a similar deployment in that I use one-way replication. It's worked well for me for a two or three years. See Migration from 10.0 to 10.2.2: Overwiting a Service

I'm not sure I follow you about managing the global ids; is replication going to replace the python truncate/append method?

If you initially replicate using existing data, the parent and child relationship is then established with synced global ids, right?  If this does become an issue for you, a decision needs to be made as to what is the value of metadata versus the value of replication.

View solution in original post

3 Replies
Highlighted
MVP Esteemed Contributor

John-  I have a similar deployment in that I use one-way replication. It's worked well for me for a two or three years. See Migration from 10.0 to 10.2.2: Overwiting a Service

I'm not sure I follow you about managing the global ids; is replication going to replace the python truncate/append method?

If you initially replicate using existing data, the parent and child relationship is then established with synced global ids, right?  If this does become an issue for you, a decision needs to be made as to what is the value of metadata versus the value of replication.

View solution in original post

Highlighted
New Contributor III

From your description, it seems that you need to keep your other databases in synchronization with your editing geodatabase. As correctly stated by Joe Borgione, setting up one way replication would be the correct approach here.

Setting up replication would be a one time process which will take care of GLOBALIDs during creation of replicas. Once it is setup, you just need to synchronize your data whenever needed (after 'editing geodatabase' is updated). This workflow may be quicker than your current workflow of truncating entire data and then appending new features.

Following link would help to understand this workflow better:

ArcGIS Help (10.2, 10.2.1, and 10.2.2)

Hope this helps!

Highlighted
Occasional Contributor III

Thank you for your feedback. Both of you have provided helpful information. The real questions is whether my workflow of publishing maintenance database edits to a read only geodatabase and then to a file geodatabase can manage a GlobalID column right now. Under the time constraints no, and we will have to revisit this at another time considering the amount of features that would require a GlobalID and the appropriate workflow. Thanks again.

Reply
0 Kudos