Preserve GlobalID on Append

02-23-2017 08:01 AM
Status: Open
Labels (1)
New Contributor III

In our environment we have several databases including a maintenance and a published environment that we replicate data to. Because or maintenance database has feature datasets (edit focused) and our published database has different feature datasets (more consumer focused) we are unable to use geodatabase replication. If data resides in a feature dataset in the source the same feature dataset must exist in the target. Because of this we have been using our own custom replication. In our replication we still want to maintain GlobalIDs in both databases, we do not want them to be recalculated as they are when you append. To maintain the GlobalIDs we have had to add an additional GUID field to our published data that we can map the GlobalID to when we append new records. This works, but it involves extra logic, an extra column and more processing time.

I recently stumbled across an environment setting in ArcGIS Pro called PreserveGlobalIDs that can be used during an append operation. This seemed quite useful as it could eliminate all the jiggery pokery we are doing now. I tried it out and there seem to be some limitations that make it pretty much useless.

The documented usage notes are below:


  • This is useful for workflows where the Global ID value for the row is required to stay the same when exporting or appending data.
  • For the Append tool, this environment only applies to enterprise geodatabase data and will only work on data that has a Global ID field with a unique index. If the Global ID field does not have a unique index, the tool may fail. To add a unique index to your Global ID field, you can use the Add Attribute Index geoprocessing tool.

The problems I have found with this are:

1) Works only in ArcGIS Pro, this is not available in ArcGIS Desktop 10.5.

2) Requires a unique index on the GlobalID column.

  •    When you create a layer in ArcGIS Pro or ArcCatalog and add a GlobalID column, the software automatically adds a non-unique index.
  • ArcGIS Desktop does not allow the user to remove the GlobalID index.
  • The GlobalID index is created as non-unique so that versioning can be supported.
  • A manual change to a system generated index is required to use this option. This manual change is in direct violation of rules enforced by other ESRI software.

I would like to see the preserveGlobalIDs setting supported in ArcGIS Desktop and to also be supported on GlobalID fields with a non-unique index as is created by the ESRI software.




This would be extremely helpful for a workflow we are using. We have an append function copying over specific records from a field survey. However, we need another script just to properly take care of attachments. This involves a recalculating of the relationship ID in the attachments table to match the new globalid. Preserving the globalid with one environment setting (as the documentation claims) would be amazing. This really needs to work outside ArcGIS Pro, as many users have server scripts on a scheduler. 


Same here!

Survey123 (which nicely supports 1:M relationships based on GlobalID) collected data has to be processed with scripts to take care of relationships. So,my vote also goes for an improvemnt in the "Preserve GlobalIDs".

Btw, attachments are indeed loaded as expected (Maintain attachments environment variable).


The inability to preserve globalids as data moves from geodatabase to geodatabase seems like a failure of imagination at Esri. Also 999999 errors are a bummer, at least add a human readable exception for the situation.


It is critical to be able to maintain GlobalIDs when transferring data from one feature class to another. As an example, we are moving ArcGIS Online accounts right now and I am re-building surveys and appending data. I am unable to run the Append tool with the "Maintain GlobalDIs" checked - I get the 999999 error. My input data is local, and the target is an editable ArcGIS Online feature layer with an exact schema match. There are 377 related records that depend on the GlobalID being maintained, and it's not possible.


Erica, if you can use ArcGIS Pro, you might try this procedure to use the append tool to migrate data and preserve GlobalID's: 


Thanks Alex, I will give that a try. Do you happen to know if this works when appending data directly into an AGOL feature service?


I would imagine it would if you have the agol hosted feature layer in Pro, but honestly never tried.


Alex, your procedure works ArcGIS Pro!!!

Only I (and we) have some other problems and frustrations.

I have a datamodel with relational tables:

  • In ArcMap 10.5 it is possible to reproject my data from AGOL (mercator) on the fly using the environment settings and set the output coordinates similar to the database (RDnew). I used it to append data to a sql-database but cannot preserve globalids and relations with related tables are lost and have try to fix them in workarounds.....
  • I have build a model in 10.5 to append datasets from several sources to a database which works perfectly, but cannot maintain globalIDs. I set the output coordinates for each append tool in the model to be sur
  • In ArcGIS Pro (2.41) the preserve GlobalID option is available, Perfect! and I can use my model.
  • it is not possible to set the environment output coordinates for the append tools...soooo disappointing....

any smart suggestions ...without that I have to use project-tool  first and create all new datasets and have to rebuild my model???




You can do it, I just did doing these steps:

  1. Add source FC to map with map coordinate system matching the source.
  2. Add target FC (which has a different coordinate system from the source FC) to map, and make sure your Transformation gets set properly when you bring it in.
  3. Open the Append tool, using the instructions above, and run it.
  4. Create a new Model or open a pre-existing model
  5. Drag-and-drop that Append you did from your Catalog History Pane into the Model
  6. (IMPORTANT) Open the Append step in your model, and reset the datatype Property to "Guid" for the GlobalID field for the output (as explained in my comment above. For some reason that setting gets reset back to "GlobalID" when you drag it from History into the Model. I have no idea why it does that.
  7. Save your Model, and Run it.

Those steps resulted in the data not only being properly projected into the target FC, but it also preserved the GlobalID value. Hope that works for you too!