This comment is somewhat off topic but related.
I have found the same situation when creating a Relationship class across a FeatureClass and say, an InspectionTable. I could not point the relationship as GLOBALID to GLOBALID.
Collector, Web Apps, just wouldn't allow for new records.
Now, we are using a BOTH direction in the relationship class so perhaps a one way would get rid of this.
The solution was to do what you did and create a GUID.
When you think this over, it actually makes sense.
I believe the following is at true statement:
All GLOBALIDs are GUIDs but not all GUIDs are GLOBALIDs
Hence, GlobalIDs are like an ObjectID and basically untouchable by the end user. The system will create & treate them as a Primary Key. At least for me, that concept helps explain this behavior.
Now not to hijack your thread, I'm going to post this question as a new thread if my Google search comes up empty handed... I have found that when I publish a layer with GLOBALIDs to ArcGIS Online (& I assume Portal but haven't verified that yet) the GLOBALIDs in ArcMap (and Pro but they were created in ArcMap) show up as all UpperCase. In AGOL, they are all lower case. It had been driving me nuts that I could not join on the GlobalIDs....
Researching that question brought me here as my top hit.
And the fact that you found is not documented is very strange. This is some fundamental stuff.
While this is a slightly different situation, it's similar in nature. Your feature class GLOBALID field needs to join to a GUID field in the standalone table. The standalone table should have it's own GLOBALID field, but that's just like the OBJECTID field: a unique id for each record. That's the way AGOL converts relationships between FC's and tables that join using OBJECTID, it adds a GUID and GLOBALID to the standalone table, a GLOBALID to the FC, and changes the relationship class to join this way FC.GLOBALID <----> TABLE.GUID
So it makes sense that it won't let you use GLOBALID on both sides of the join because the GLOBALID values need to be unique inside a Geodatabase across all items.
Thank you! This is exactly what I needed. We were trying to Append from fgdb to SDE and getting a 999999 error when Preserve GlobalID was selected. Now that I think about it, makes sense that the target must be of data type GUID, though, preserving the GlobalID should automatically set the target to GUID data type, or at least throw a more useful error.
Thanks for posting this!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
I was getting the same 9999999 Michael was seeing and couldn't figure out why.
Alex Friant I have attempted your steps to Preserve the GlobalID field when achieving data. In my case, the GlobalID were not preserved even with the box checked.
I do run into the same issue of the original problem as the append tool does not work unless the GlobalID field type is changed to GUID. However, in my case the GlobalID field is still not being preserved.
Have you ran into this issue as well?
My solution turned out I needed to add an index to my archived feature class (Target Dataset) as the GlobalID field and set as unique. The append will run without making adjustments to the field map.
Interesting. The "Add Global IDs" tool adds the index automatically, so perhaps it was added manually or the index was removed by accident? Either way, glad you got it figured out!
The Add Global IDs is something we have to do when creating the new feature class on the server. However, I don't believe it sets it to "unique" under the index properties so I have to go back in and add a new index pointing to the GlobalID and set it as "unique".
.....seems like unnecessary steps that should be already set in place.
My GlobalID index is marked as "No" for Unique, but it still worked. Does that same FC has an ObjectID field with an index set to Unique = 'Yes'? Mine does. I downloaded the FC from AGOL at one point, so perhaps that's