How to export version changes from one GDB to another?

895
1
Jump to solution
09-21-2016 10:01 AM
Highlighted
Occasional Contributor

I'm using arc gis 10.2.1.  I have created 90,000 point features in a versioned point feature class and updated about 90,000 rows in a versioned object class that is related to the point feature class.  The object class is related to the feature class using the objectid of the feature.  I made my changes in a version off SDE.DEFAULT.  A co-worker wants to make the same changes I made repeated in a versioned geodatabase he's using.  His geodatabase has the same schema as mine.  What's the best way to get my co-worker these same changes?   I can see the inserts and updates in arc map in my GDB using the version difference tool.  We don't have a license for the "Data Reviewer" tool from esri.  If it was just 90,000 new points, I could export these to a shapefile and send him that.  But I've also got the changes to the object class that is related to the feature class.  I'm not sure how to get him these changes.   The geodatabases do not use global ids.

Tags (1)
0 Kudos
1 Solution

Accepted Solutions
Highlighted
Regular Contributor

This is an example of why you cannot safely use ObjectIDs for relationships or joins; they can have gaps due to editing and the gaps will be missing or different in another feature class, or if rows are deleted and reloaded. This gap problem is even true with the outputs of geoprocessing tools. In our conversion to SDSFIE 3.1, we added a business table key. This can be set to the ObjectID or the ObjectID plus/minus some number, but it will never change unless you need it to. It has the same field name in the feature classes and business tables, and the same name across features and tables, so it is easy to work with.

If you have a safe key that won't change, your coworker could add the new points with the safe key field, clear out the related object, and add the changed ones in as new. You should be able to export the related table from your edit version.  Without seeing the data, I am not sure about the best way to tackle this; I would personally do lots of staring at the data, summarizing, and joins to analyze what is in which file before proceeding. 

View solution in original post

0 Kudos
1 Reply
Highlighted
Regular Contributor

This is an example of why you cannot safely use ObjectIDs for relationships or joins; they can have gaps due to editing and the gaps will be missing or different in another feature class, or if rows are deleted and reloaded. This gap problem is even true with the outputs of geoprocessing tools. In our conversion to SDSFIE 3.1, we added a business table key. This can be set to the ObjectID or the ObjectID plus/minus some number, but it will never change unless you need it to. It has the same field name in the feature classes and business tables, and the same name across features and tables, so it is easy to work with.

If you have a safe key that won't change, your coworker could add the new points with the safe key field, clear out the related object, and add the changed ones in as new. You should be able to export the related table from your edit version.  Without seeing the data, I am not sure about the best way to tackle this; I would personally do lots of staring at the data, summarizing, and joins to analyze what is in which file before proceeding. 

View solution in original post

0 Kudos