topic Re: GlobalID inconsistent display in ArcGIS Pro Questions

GlobalID inconsistent display

DougBrowning — Thu, 31 Oct 2019 16:28:51 GMT

I am seeing that the Attribute Table and the Attributes pane show GlobalID differently. One is all upper case and one is lower.

I would call it a bug.

thanks

Re: GlobalID inconsistent display

GarrettSeay1 — Thu, 31 Oct 2019 16:50:10 GMT

ArcMap has them all capital letters in Attribute pane, Attribute Table, and Identify Table.

I would agree with you.

Re: GlobalID inconsistent display

KoryKramer — Fri, 01 Nov 2019 14:39:33 GMT

I don't see this in a dev build of ArcGIS Pro 2.5:

Re: GlobalID inconsistent display

GarrettSeay1 — Fri, 01 Nov 2019 16:18:44 GMT

Just tested in ArcGIS Pro 2.4.0 and didn't see it as well:

Re: GlobalID inconsistent display

DougBrowning — Thu, 14 Jan 2021 21:16:28 GMT

I am not the only one seeing this still.

https://community.esri.com/t5/arcgis-collector-questions/are-the-arcade-featureset-functions-supported-in-collector/m-p/1017061

Re: GlobalID inconsistent display

James_Whitacre — Mon, 12 Apr 2021 14:14:13 GMT

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?

Re: GlobalID inconsistent display

DougBrowning — Tue, 21 Sep 2021 19:51:14 GMT

Actual video of it happening @James_Whitacre . These came from 123, where some but not all forms store as lower. I cannot even figure out which one is "correct". I posted to 123 and they do not think it is an issue but it for sure is. thanks https://community.esri.com/t5/arcgis-survey123-questions/globalid-in-lowercase-from-collector-to-survey123/td-p/822843

Re: GlobalID inconsistent display

DougBrowning — Thu, 16 Dec 2021 14:49:05 GMT

Ok this one is getting me in the web map now.

It shows globalid as lower case in the attribute table but when I run a simple calc to put it into the FormID field it suddenly goes upper case!

Now the super fantastic part is relationship classes see the uppercase and lowercase as different so it breaks all the relates!

At this point how are we supposed to program around all of this? I know this is not really Pro at this point but these kinds of inconsistencies is a killer. I am still not sure which is correct? What is the Esri standard?

Looking at this in Pro 2.8 I am still seeing the popup be different. Have the others that posted tested opening up a Web map in Pro. That is where I see this. When I open I GDB they are both caps.

Can we please hear from anyone?

Thanks

Re: GlobalID inconsistent display

DougBrowning — Thu, 16 Dec 2021 15:16:26 GMT

@GarrettSeay1 I think this is because your original table is uppercase. Try a lowercase globalid and see if the popup turns it to caps.

Re: GlobalID inconsistent display

DougBrowning — Thu, 16 Dec 2021 17:56:24 GMT

Am finding that both Field Maps are 123 are doing lowercase but AGOL does upper.

See more examples here

https://community.esri.com/t5/arcgis-field-maps-questions/field-maps-is-creating-lowercase-globalid-but-agol/m-p/1126803#M2101

thanks

Re: GlobalID inconsistent display

DougBrowning — Tue, 25 Jan 2022 18:35:55 GMT

Since I am not getting anywhere I went to support. They agree 123 and Field Maps is doing lowercase when everyone else is doing upper. But they say it is not a bug but an enhancement.

ENH-000130624

One possible workaround I am testing is to make any ID field a GUID. GUID does not seem to care about upper and lower so the relationships work. It is harder to use a GUID and it forces me to add the {} and it cannot be a diff text key which is a bummer.

Also even when I paste in a upper GUID it changes it to lower in AGOL

But In ArcMap they are all upper and show as upper.

So AGOL, 123, and Field Maps is all lower or shows lower but ArcMap, Pro, SQL, etc it is all upper and shows upper.

For sure a inconsistency that is very confusing. I hope all the teams can just agree on one choice and use it.

Also 123 uuid() does all lower.

Going to try and get it escalated so hope 123 can make the switch.

thanks

Re: GlobalID inconsistent display

DougBrowning — Wed, 02 Feb 2022 15:16:10 GMT

Esri now agreed to update this to a bug BUG-000146406

thanks

Re: GlobalID inconsistent display

DougBrowning — Mon, 15 Aug 2022 20:22:58 GMT

@James_Whitacre more proof for you.

Just proved today that if you use the Attributes window to edit in Pro it will change the 123 parentGlobalID field to uppercase - and this does break the relationship! Support said that would not break it but it for sure does. I thought so also as did @JamesTedrick

If you use Field Calculator it will not change to upper case so use that.

FYI to all.

Re: GlobalID inconsistent display

James_Whitacre — Fri, 19 Aug 2022 14:46:57 GMT

@DougBrowning I tried to be very clear about the severity of this bug...hopefully they continue to listen. Were you using ArcGIS Pro 3.0 or 2.9.x?

I have since moved on from the project where I was dealing with this issue and it hasn't resurfaced (yet!!) in any new projects...

Re: GlobalID inconsistent display

DougBrowning — Mon, 29 Aug 2022 16:44:35 GMT

Using 2.9. You are right how has this gone on this long? I mean editing in one Esri product breaks the other product it not great. I wish Esri had some type of central data standards board on all this stuff. It is not the first inconsistency for sure. I think the teams all work on their own little islands, does not work out well.

Re: GlobalID inconsistent display

MattStarryACE — Thu, 17 Aug 2023 13:54:31 GMT

Using Pro version 3.1.2. Published a service with existing relationship class to AGOL from Pro (3.1.2). Right-clicked on relationship in Attributes pane and selected "Add New To Relationship". It added a record to the related table but it is not recognized because the table is populated with GlobalID and related GUID field in ALL CAPS. Very frustrating that this does not work in "Pro".

Even inconsistent when viewing the table in 'Show Selected' vs 'Show All'.

Show AllShow Selected

Re: GlobalID inconsistent display

DougBrowning — Thu, 17 Aug 2023 13:56:15 GMT

Bug is still in review. If you have access to support you can add to it or escalate it.

Re: GlobalID inconsistent display

bcdi — Mon, 11 Dec 2023 05:03:25 GMT

Getting to the end of a very long analysis and this issue is jamming me up hard. For what it's worth, I'm using 3.2, windows 11 via parallels.

Edit: upper-ing (yep) the (correctly lower-ed) GlobalID in the raw file of the join table allowed for a successful join. Still unfun to have to navigate.

Re: GlobalID inconsistent display

ClangDevGuy — Tue, 30 Jan 2024 20:20:28 GMT

Just wanted to share more frustration with another issue that I found with this GlobalID inconsistency. It is even effecting the new Enterprise 11.2 Experience builder application where the internal esri team seems to be having similar issues themselves.

I'm basically using the "Data Actions" to query related records from a feature to a feature table. I have GlobalDs and GUIDs for the relationship and the internal built query for selecting sites now uses a "LOWER" in the where statement:

Ex:
(((LOWER(SiteGUID) = '{f725dad7-5205-41d3-956c-1b1a45ff680f}')))

Result is 0 records now, because this was programmed for the "AGOL" globalIDs and not the "Arcgis Portal" globalIDs.

Re: GlobalID inconsistent display

DougBrowning — Tue, 30 Jan 2024 23:26:49 GMT

Did some digging and it is now been moved to a bug BUG-000146406. So some progress at 4 years. If anyone can escalate please do.

https://support.esri.com/en-us/bug/inconsistent-letter-cases-for-the-global-id-values-betw-bug-000146406

It is not just Pro of course though

BUG

Inconsistent letter cases for the Global ID values between ArcGIS Desktop and ArcGIS Online products.

Last Published: February 18, 2022

ArcGIS Pro

Bug ID Number BUG-000146406

Submitted	January 27, 2022
Last Modified	January 5, 2023
Applies to	ArcGIS Pro
Version found	2.9.1
Operating System	Windows OS
Operating System Version	10.0 64 Bit
Status	In Review

Workaround

For relationship class operations, use a GUID field as the destination key.

Bug ID: BUG-000146406

Software:

ArcGIS Pro