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
@PancovaMarketa Thanks for posting. Not sure why it took 5 years to get a bug logged I thought it was on the list when I reported in 2019. I talked to the Pro team about it directly also.
There is a BUG-000169450 related to this.
I just posted in the other thread about this @DougBrowning then found this one. Very frustrating that it's still an issue 6 years on!
I'm running into this issue in ArcGIS Pro 3.5.0.
I have a point dataset with related table using GlobalID to a GUID field, set it up and Pro, worked okay, uploaded it to AGOL and now when I view in Pro I can't see the related records - if I select a record and click on Related Data, it shows the relate exists but there is no number next to it indicating how many records are related. I can however see the related records using the pop-up window.
The only potential cause I can see is this uppercase/lowercase issue.
@BenGunnewijk , as much as I agree that consistency within and across a company's product lines is important, I am interested in what "GUID standards" you are referring to? ITU-T X.667, RFC 4122 (now RFC 9562), or some specific company's implementation like Microsoft (based on RFC 4122)? Or is it really about Esri just being consistent with their own Global ID implementation?
I have not tested in a bit but try making an edit and see if it changes it on you.
2-cents,
ArcGIS field data types
(ArcGIS Pro 3.3, 3.4, 3.5)
https://pro.arcgis.com/en/pro-app/latest/help/data/geodatabases/overview/arcgis-field-data-types.htm#ESRI_SECTION1_91A7053C06624624ABEE2E6765F15083
Hi @DougBrowning
I looked at this in ArcGIS Pro 3.5.1. While the GlobalID in ArcGIS Online displays with lowercase letters:
When added to ArcGIS Pro, it displays uppercase, in the attribute table and attributes pane:
The pane is also showing that I was able to successfully join local data to the hosted feature layer from Online using globalID, even though one is stored uppercase and the other lowercase.
Are you still running into interoperability issues?
@BenGunnewijk I met with the ArcPro team in person at DevSummit and they are looking at it. Maybe @KoryKramer can update.
Did confirm there is no standards board at Esri and there really should be. All companies struggle with consistency of course and it leads to a lot if interoperability issues.
Thank you Doug for your persistence on this issue that really should be fixed ASAP.We ran into query issues in our FME -> ArcSDE flow. After a lot of debugging it turns out ESRI should give a few more **bleep** about GUID standards.
If you have any options to escalate the bug via your support please do.
ENH-000130624 and BUG-000146406 : Upper and lower case globalids
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?
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
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-000167548Additional Information: Duplicate of BUG-000167548Alternate Solution:
For relationship class operations, use a GUID field as the destination key.
Thank You,
Not sure it has been a bit since I messed with it. We have to stay away from Pro edits now as it breaks everything. I think editing in the Attribute table is doing it still as I saw that a few weeks ago.
I have even talked to Esri staff on this personally several times. Just looked and its almost 5 years now which is just crazy pants. It really speaks to the communication and standardization issues and strange prioritization that goes on at Esri though. This is not a isolated issue on bugs and it really holds the company back more than they realize.
Hi Doug,
Can you confirm if the above method (using Field Calculator) still works for leaving GlobalID fields in lower case? I have run into this issue periodically over the years, and I feel like your statement was correct at one point, but currently I am seeing the capitalization issue after performing edits via both Attributes window and the Field Calculator. Kind of surprised this is still an issue, it's been around for awhile now.
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.
On it...this is unbelievable.
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
Bug ID: BUG-000146406
Software:
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.
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.
Bug is still in review. If you have access to support you can add to it or escalate it.
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
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.
@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...
@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.
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
@GarrettSeay1 I think this is because your original table is uppercase. Try a lowercase globalid and see if the popup turns it to caps.
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
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
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:
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...
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?
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
Just tested in ArcGIS Pro 2.4.0 and didn't see it as well:
I don't see this in a dev build of ArcGIS Pro 2.5:
ArcMap has them all capital letters in Attribute pane, Attribute Table, and Identify Table.
I would agree with you.
Přihlášení členové mohou přispívat, sledovat aktualizace a další. Jste tu noví? Zaregistrujte si bezplatný účet.
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.
