GlobalID inconsistent display

[DougBrowning]

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

[MattStarryACE]

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

[DougBrowning]

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

[bcdi]

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.

[ClangDevGuy]

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. 

[DougBrowning]

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-00014... 

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

[ahargreaves_FW]

On it...this is unbelievable.

[DougBrowning]

Yes I agree and it has been over 3 years too.  Shows a lack of communication between teams.  I talked to them in person about it a few times too.  no movement which is weird.

[DougBrowning]

Got this update today.  Of course you cannot change to GUID in 123 land.  They still do not get the problem.

Bug fixes are addressed in upcoming releases or general patches, or they may be addressed as ad-hoc fixes. Enhancement requests are implemented in upcoming releases.

Updates have been made to the following defect which you are associated with:
BUG-000146406 - Inconsistent letter cases for the Global ID values between ArcGIS Desktop and ArcGIS Online products.

Status: Duplicate (Learn More)
Duplicate record #: BUG-000167548
Additional Information: Duplicate of BUG-000167548

Alternate Solution:

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

Thank You,

[MarkWILSON_LLS]

Ive only just come across this problem trying to update geometry between local and agol data. talk about frustrating.. 
Thanks for all your efforts on this one @DougBrowning 

FYI - bug fix doesnt work for me as my AGOL Schema is locked (Another bug bear about best practice using joined views on hosted data) . - I did manage to create a string field on the local data with a lowercase copy of the GLOBAL_ID and link the data that way.
mw

[EKulack]

I published a hosted feature layer from Pro that's referenced in a Survey123 form that has a table with several layers related to it. Upon publishing, the global ids for the parent table change from upper to lower case, in Pro at least, thus breaking the relationship because of a casing mismatch. Of course you can't change the casing of the related GUID fields. The fun part is, if I export/download the feature layer the globalids for the table revert back to upper case!

Why is this still an issue? This should be a basic data integrity fix—yet users are stuck wasting time troubleshooting workarounds. I've personally spent way too much time trying to problem solve this issue and couldn't believe this has been a reported issue for 5 years. Fix it, standardize it, or give us a setting to control case handling. Incredibly frustrating. 

When will Esri address this?