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:
(from: http://pro.arcgis.com/en/pro-app/tool-reference/environment-settings/preserve-globalids.htm)
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.
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 perfect....in ArcGIS Pro!!!
Only I (and we) have some other problems and frustrations.
I have a datamodel with relational tables:
any smart suggestions ...without that I have to use project-tool first and create all new datasets and have to rebuild my model???
regards,
Stefan
You can do it, I just did doing these steps:
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!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.