THIS IS A SERIOUS ISSUE THAT ESRI NEEDS TO ADDRESS ASAP!!!
ESRI PLEASE ADDRESS AND SOLVE THIS ISSUE!!
I am also seeing this issue. I am not working in Survey123, but I am working with an ArcGIS Online feature service using a one-to-many relationship between point feature layer (key field: GlobalID) and polygon feature layer (key field: GUID), which is how Esri suggests creating relationships.
I don't want to get into the details of my use case because it is a bit complicated and I can't yet share my code, but here is the basic pseudo-workflow in Python (Note: 'feature layer'=ArcGIS Online; 'feature class'=file GDB:
- Copy the selected point feature layer to the local scratch GDB as a feature class. (Note: Yes this is needed...too many details to explain why...no comments on this please)
- Use a arcpy.da.SearchCursor to extract the field values from the point feature class that will be populated to the polygon feature class, including the GlobalID. (Note: I think it is at this point that the GlobalID is converted from lowercase alpha chars in the feature layer to UPPERCASE alpha chars in the feature class. It also appears that the GlobalID field is converted to a string Python data type by the cursor.)
- Series of arcpy geoprocessing tools to create the feature class polygons in the scratch GDB. A GUID field is created in this step and calculated from the search cursor GlobalID of the point feature class. I also add '.lower()' to the GlobalID string. It calculates, but is still UPPERCASE alpha chars.
- Feature class polygons are appended to the polygon feature layer. Polygon feature layer GlobalIDs and GUID values retain UPPERCASE alpha chars.
So what happens to the relationship? When selecting the point features in the feature layer, the polygons do NOT show up as related. BUT! When I select a polygon from the feature layer, the point feature shows up in the relationship! Super weird...lowercase-to-UPPERCASE does NOT work, but UPPERCASE-to-lowercase does work!?!?!?
So, here are my questions...
- WTH is going on?
- Why are the AGO feature layers able to accept both lowercase and UPPERCASE GUID values, but file GDB feature classes only seem to accept UPPERCASE?
- Why does the relationship work one way, but not the other?
- Is this issue at the OS/Windows level with how it deals with UUIDs?
- Why does the GlobalID come out as a string datatype instead of a UUID or other class or byte-type?
- Do joins between GlobalIDs and GUIDs act like strings? If so why?
At any rate, all of this seems like some major design flaws that need to be fixed or tightened up. If Esri is going to tell us to use the GlobalID-to-GUID relationship key structure, these field-types and value-types need to be very strict. I thought they were...clearly I am WRONG!
Sorry for the rant, but this could derail a major project I have been working on for some time and this may require that I go all the way back to my GDB schema design and rework all of my Python code, and I do not want to do that.
EDIT: So, a workaround I discovered (that will NOT require me to go back to square one!) is to calculate the GUID field in the polygon AGO feature layer so that the values are lowercase (e.g. !GUID_Field!.lower()). While this will work, I still stand by my comments above, and I would hope that any programmer would agree that this is a flaw and that this extra step is asinine.
EDIT: Now the Append tool is refusing to append the GlobalID to the GUID field so the relationship can be made. This has really turned into a massive CF (sorry for the foul reference, but there is no other better descriptor...). Esri, any feedback here?? Please?
