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

[DougBrowning]

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

[DougBrowning]

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

thanks

[DougBrowning]

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

[DustyJordan]

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. 

[DougBrowning]

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.

[DustyJordan]

Thanks for the response, Doug. What is your workflow, or what would you recommend, for QA/QCing field data collected from Survey123 forms? Particularly doing batch edits across many records.

I have created numerous forms for all of our field data collection and my goal was to train my coworkers on how to QA/QC and error check each of their datasets in ArcGIS Pro. I'm now realizing this is going to unleash a Pandora's Box of broken relationships. 

[DougBrowning]

Do some testing but I think that using Field Calculator it was ok.  Just not editing in the table row by row or using the attributes window.  

New Map viewer also just released a field calculator but I have not tested it yet.  

We use dashboards a lot linked to a Field Maps form or a 123 widget also.  But now with Dashboards adding simple editing last week I would also look at that.  Experience Builder has 123 widget and tables also.  Little more work but our dashboards came out super slick and only show what needs to be fixed.  We do not want our users in Pro anyway too easy to get in trouble.

I never use globalid in my relates for a number of reasons but this is one of them.  We have our own human readable key we construct that is preloaded in field maps then passes to 123 parent and then down into the child.  In QA we often have to fix all these if the user picks wrong but its ok.  We download and process into SQL at the end of the field season so globalid would never work out for us.

Hope that helps a bit

[DustyJordan]

Thank you Doug, this helps a lot. 

Dashboards was where my head was going as well. Our project has multiple biologists each managing their own task, which each come with unique data needs. The thought of having each of them tinkering in ArcGIS Pro, with varying GIS skill levels, has me more than a bit nervous. I really like the idea of designing each of them a custom dashboard. I haven't done anything in Experience Builder yet, but I'm looking forward to diving into it when I get time. 

At one time I had started using unique site acronyms and concatenations to construct custom key fields in S123, however it became kind of messy to keep up with and I ended up reverting to relying on GlobalID/GUID fields, as it just seemed easier. Maybe this is something I should revisit and come up with a schema/format that is a little more robust. The groundwork is already somewhat there. 

Thanks again!

Edit: I was under the impression Dashboards were created using Experience Builder, but I'm now realizing those are two different applications. I'll have to take a deeper dive into both.

[James_Whitacre]

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

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.