GlobalID inconsistent display

2999
19
10-31-2019 09:28 AM
DougBrowning
MVP Esteemed Contributor

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

Tags (1)
19 Replies
DougBrowning
MVP Esteemed Contributor

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

 

DougBrowning_0-1643135731418.png

 

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

DougBrowning_1-1643135731420.png

 

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

 

DougBrowning
MVP Esteemed Contributor

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

thanks

0 Kudos
DougBrowning
MVP Esteemed Contributor

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

James_Whitacre
Occasional Contributor

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

DougBrowning
MVP Esteemed Contributor

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.

0 Kudos
MattStarryACE
New Contributor

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 AllShow SelectedShow Selected

DougBrowning
MVP Esteemed Contributor

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

DougBrowning_0-1692280551784.png

 

0 Kudos
bcdi
by
New Contributor

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
New Contributor III

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
MVP Esteemed Contributor

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
SubmittedJanuary 27, 2022
Last ModifiedJanuary 5, 2023
Applies toArcGIS Pro
Version found2.9.1
Operating SystemWindows OS
Operating System Version10.0 64 Bit
StatusIn Review 
 

Workaround

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

 

Bug ID: BUG-000146406

Software:

  • ArcGIS Pro