The spirit of this post is to gather other people's solutions, discuss ways of improving the suggested solution, and track future ArcGIS capabilities as they evolve for this problem.
This all started because we had existing data in a GDB that contained a Relationship Class (RC) between a Feature Class (FC) and a Table (TBL) using the FC's GlobalID field. We wanted to move that data into a new GDB that had a new schema (changes in domains, fields, etc.).
The problem is that when you Append the old data into the new schema, the GlobalID in the new schema is different than the records from the old data. This breaks the relationship between the FC and the related TBL.
UPDATE 2:
I've got some bad news and I've got some good news. And some ugly details. But I also have steps/options.
The BAD news
The "New Solution" from my first update no longer works in Pro 3.x, as so kindly brought to our attention by @MichaelMannion a few days ago in this reply. Thanks Mike!
Basically, ArcGIS Pro no longer allows you to change the datatype for step #8 in the solution below. This breaks the solution I originally provided.
The GOOD news
ArcGIS Pro 3.x now respects the "Preserve GlobalID" environment option in the Append tool, but with very specific parameters. It works if the target database is either Enterprise Geodatabases and Mobile Geodatabases, but not File Geodatabases.
The UGLY details
In order for the Append tool to actually preserve the GlobalID from your source to your target, you still need to check the "Preserve GlobalID" environment option in the Append tool.
You can only get it to work with Enterprise Geodatabases (EGDB) and Mobile Geodatabases (MGDB) as your targets, as no longer works with File Geodatabases (FGDB). Here's why.
The target GlobalID field must have and index that is configured as "unique". You can't make a GlobalID field that has a unique index in a FGDB.
Unique and ascending indexes are not supported for shapefiles or file geodatabases. These parameters are ignored when the tool is executed on a shapefile or file geodatabase data.
A 'unique' index can only happen if:
When you follow those two parameters, the index that gets automatically created for the GlobalID field that is has the unique setting.
If your target field is a GUID datatype, it must also have a "unique index". You must use add the index in ArcGIS Pro, on an EGDB table/feature class, and make sure the "unique" checkbox is selected before you run the Add Attribute Index tool.
The STEPS for Enterprise Geodatabases/Mobile Geodatabases
Below I only refer to EGDB, but if you're using a MGDB the same steps apply.
Once your data is in the updated schema, you can copy/paste it over to a File Geodatabase if you need to (for a deliverable or something).
The STEPS for File Geodatabases
All hope is not lost for users who must be restricted to File Geodatabase only. (But really, there is no reason to be afraid of the Mobile Geodatabase as a in between step, it works well!).
Thanks to user @DirtDogRoj in his excellently documented reply you can follow clearly outlined steps to achieve the same result. I think you could put it into Model Builder even as all the steps very systematic. You might like this method better just because! 😉
Pay no attention 2:
UPDATE 1:
I have a much, MUCH, better solution that I discovered and it doesn't appear to be documented anywhere. All the text below that has strikethrough you shouldn't pay attention to, as it was the old, convoluted solution.
New Solution:
Pay no attention 1:
After doing some searching, I discovered that there is a way to do this using and Enterprise Geodatabase (EGDB) and ArcGIS Pro.
I post my basic workflow here on how to preserve the FC's GlobalID values so that when you migrate the data over to the new schema, the GlobalID values stay the same in the new FC. This preserves the relationship between the FC and the TBL in the new schema.
Assumptions:
Manual Steps:
At this point, you can now copy/paste that new FC back to your location of choice, and rebuild the RC so that it connects up with the new TBL. It turns out that the GUID's used in the related table to relate back to the FC are naturally preserved by using the Append tool in ArcCatalog, so performing the workflow above on the related TBL is unnecessary. Even though the TBL's GlobalID (not GUID) values change when moving the data, that's doesn't matter to us because they aren't used to create the relationship.
We don't do this often so we aren't going to take efforts to automate it, but I assume that might be possible.
Alex, I don't believe I tried Kyle's solution. I ended up getting around my issue with a manual update (and using a Technician), but when I have some time to kill I will try his solution on another test dataset. Thanks.
Great idea and I like the overall concept when updating Hosted FClass. Definitely hHave to remember this one next time an update gives me grief which seems to be quite often
Thanks for sharing!!!
-Paul Davidson
Hi. Trying to append features from a FGDB in Pro (2.6.0) to Hosted Feature Service on ArcGIS Online. Tried everything in this thread with no luck. Keep getting the same error
WARNING 000594: Input feature 1: Function not implemented. whenever the "Preserve GlobalIDs" box is ticked.
Anyone come across this? Or have a solution for preserving GlobalIDs when appending to AGOL Hosted Feature Layer? Thanks.
I never tested this out by using an AGOL HFL as my target. Let us know if you find a solution.
Hi Scott,
I am running into this issue now. Did you ever find a solution? I'd been able to successfully use this workflow with HFL in the past, pre Pro 2.6.
Erica
Unfortunately not.
We have just resigned to the fact that it does not work and have created complex workarounds to grab the GlobalID from features once they are published.
Can I publish feature layer/service from GDB/Pro to AGOL while preserve the GlobalID? If I use the GlobalID/GUID as the primary/foreign keys of relationship class, what will happen after I publish both feature class and related table to a AGOL feature service?
Thanks,
Ming
As long as your relationship is defined before publishing the data to AGOL, you should be fine and the relationship will remain. I am not sure if the GlobalID/GUID values will be the same as what you've got recorded in your local fGDB though - that's something I have never checked.
Thanks Erica!
Ming
I think there is confusion between Global ID data type and GUID data type.
You can have any field as a GUID field which you can manage by yourself. You can manually create a unique field, call it whatever, a GlobalID and make it a GUID data type. This field will be like any other field you create in the database. But if you want the geodatabase to take care of the unique number for your rows then you add the GlobalID field through the database management dialog and that field will have Global ID data type and will be managed by the geodatabase. You won't be able to copy data in to it, append, load or even delete it.