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:
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:
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.
Another idea is memorialize the GlobalIDs in the Feature Class (create new field called [GBL_GUID], GUID type --> Field Calculate the [GBL_GUID] field to the values in GlobalID). Now, if you export any data from that Feature Class in whatever database format.. the relationship will be maintained through the new [GBL_GUID] field.
Great answer, thanks! Your solution is better because once the change is made, then I never have to deal with the issue again after changing schemas. Thanks again.
After further testing, Mitch's solution won't work for us. The GUID field created doesn't autopopulate with a GUID in either ArcMap nor ArcGIS Online once deployed. Unless there is another trick to it, I'll have to stick to my original solution.
Have your DBA to a SQL update to the rows every x amount of time.
The data is to be hosted in AGOL eventually, so hacks won't work.
Will since you have an EGDB.....this is another one of those "Tech support will disown you" hacks #if they catch you doing it but...
In SQL Management Studio, change the object_flags to 4 (from 256) and sde_type to 14 (from 12) for the GlobalID column in SDE_column_registry for both feature classes. Then do you move. Remember to change them back!
Thomas, check out the update in my original post. I found a very simple, supported, non-hack way to do this using ArcGIS Pro.
very handy! I wonder if this can be mixed with some other python tools for archiving and downloading between AGOL and on-premise databases to achieve a true "two-way" sync without having to rely on flaky portal or pay for a data interop license.
I don't see why not. The Append Tool should be scriptable, but I haven't had time to look into that yet. It's a good idea!