• ArcMap 10.2.2 for Desktop
  • License Type: Advanced
  • Python 2.7.5

Our SDE contains feature classes that use GlobalIDs for replication. I am wanting to create a script that will run nightly backups on this SDE. I have done plenty of scripts like this in the past but I haven't had to work around GlobalIDs before.


  • If I simply go into catalog and highlight the feature classes that I need I can right click, copy, and paste into a new GDB and that will keep my GlobalIDs for all my features. But this is just a manual way of doing it that I know will work, but not what I need for automatic nightly runs.
  • If I do arcpy.FeatureClassToFeatureClass_conversion() this will keep the GlobalIDs field but generate new GlobalIDs for me.
  • If i do arcpy.CopyFeatures_management() this will remove the GlobalIDs field completely when moved into the new GDB.

I am hoping there is a way to mimic the manual 'right click copy/paste' method in python.

  • We ran into this same issue last year, and had the exact result when testing - right-click copy/paste copies the Global IDs as desired, but FC to FC and Copy Features either created new IDs or removed the field completely. I will look up my emails from then to see if we found a solution (although I don't believe we did).
    – Midavalo
    Commented Jan 23, 2017 at 19:11
  • I appreciate your time in looking. Commented Jan 23, 2017 at 19:32
  • If using Pro, there is an environment setting to maintain globalID google.com/url?sa=t&source=web&rct=j&url=http://… Commented Jan 24, 2017 at 3:54

2 Answers 2


I think you are after copy management


From a quick bit of testing on fgdb's this appears to work.



We are doing the same thing. We want to retain GlobalIDs on our custom replication and for backups. By keeping the GlobalIDs as key fields we can compare the current data to the backup or the published data to see if there were any changes and if replication or a backup is necessary.

(Copy_Management will copy related feature classes to the 3rd level but no further. This would bring across too much data in some cases and not enough in others for our purposes.)

Replication: We use custom replication because GDB replication doesn't work for us as our source and target objects are in different feature datasets. To replicate we basically do an append of new/mod objects to the target objects. We do this via an append method using a field mapping. We map the source GLOBALID field to a dummy column that all our target objects have called GLOBALID_GUID (type GUID). Once the data is appended we do a SQL update to calc the GLOBALID = GLOBALID_GUID, this is run against the base and the A table.

Backups: We do database level backups but they don't work so well for versioned data so we also do a backup of each object as a separate file geodatabase. Here we also use row level change detection to determine if we need a new backup. The GLOBALID functions as the key field between the current data and the backup. To backup the data we use the FeatureClassToFeatureClass for layers and TableToTable for tables. Both these operations will create new GLOBALID values for you but I have found if you first make a QueryLayer of the source data you can get the GLOBALID into a simple TEXT field. My query for the QL is something like "SELECT OBJECTID AS ORIG_OBJECTID, GLOBALID AS GLOBALID, SHAPE, OTHER FIELDS.... FROM SOMETABLE".

In the case of versioned objects I replace SOMETABLE with SOMETABLE_EVW which gives the data from the SDE.DEFAULT version. If you want a different version you can wrap the set version stored proc from ESRI into a function and embed it into your query that seems to set the version first before returning the data. (We are just implementing this and it seems to work so far.)

There are a few gotchas with the QueryLayer method. 1) Versioned data must have an EVW. 2) The QL doesn't seem to like null geometry where SDE.ST_ISEMPTY=1, in that case it prefers a NULL value, so you have to convert those via something like: DECODE(sde.st_isempty(shape),0,SHAPE,1,NULL) AS SHAPE 3) Another thing about query layers is that when used by arcpy it ignores your key column and instead uses the first column in your query statement, so if your query does not start with a unique column such as OBJECTID or

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.