Why won't Pro sort on Global ID?

[ThomasColson]

So in troubleshooting this: 

I can in Arc Map do this: 

Which gets me to the offending row, from which I can figure out what is wrong with an attribute or geometry that's causing the issue. From there I can make a decision to delete the feature, go under the hood in SQL to edit something, edit it in SDE, or create a local copy. Take home message is, via the feature service, I can sort on GlobalID. 

In Pro...cannot sort GlobalID from a feature service. I can from a .geodatabase or a feature class, both of which take time and more mouse clicks to bring into a map but not a feature service. Is there a valid reason why this capability was removed?

[JonathanFarmer_oldaccount]

Tom,

Well I thought I could reproduce this but now I'm not so sure.

ArcMap, both online and offline and Pro, offline, sort like this:

Ascending: {E13D9E6D-06CC-4CCF-9BC6-0011D61A3DDB}

Descending: {66595284-1337-4B3C-B315-FEE424F42CF0}

You can see that it is starting its sort with the last set of numbers (0011D61A3DDB vs. FEE424F42CF0).

But I still see that same sorting behavior with Pro online as well. We are still sorting by that last section. 

It is hard to see from the GIF exactly what is happening on your end. Can you attach a video to this thread so I can take a closer look at the differences between Pro online and offline on your end?

Jonathan

[JonathanFarmer_oldaccount]

Hi Tom,

OK, I see what you do in the video but I want to make sure all the scenarios match up.

When I am working with a feature service or data coming from an enterprise geodatabase, either in ArcMap or ArcGIS Pro, I see that we sort the GlobalID fields by the last set of characters.

Ascending: {E13D9E6D-06CC-4CCF-9BC6-0011D61A3DDB}

Descending: {66595284-1337-4B3C-B315-FEE424F42CF0}

However, when working with a mobile geodatabase, we sort that same GlobalID field by the first set of characters. We also sort this way for a file geodatabase.

Ascending:

{091A6365-E29F-487A-A063-3376D024AF24}

Descending:

{898F25E2-5740-450E-8E04-1441F3F51ECC}

I see this same behavior in both Desktop clients and at different versions of each so it does look like this is expected. But from what you are telling me, you see ArcMap sort feature services and enterprise geodatabases by the first set of characters and not the last? If that is the case it may need a Support case because that isn't what you should see based on testing this here.

Jonathan

[ThomasColson]

Hmmmmm...if I call TS...it will get "fixed", and I no longer will be able to sort using the first octet in Arc Map....

Let's look at a work around: There's something wrong with GlobalID {09BE107D-DF2B-4FAB-A24E-02F464EDA029} according to the server logs. That's all the info I get. Not ObjectID, not primary display field, nothing. In Arc Map, I can sort the feature service and easily find {09BE107D-DF2B-4FAB-A24E-02F464EDA029}. Neither in Arcmap or Pro can the Find (Locate) tool be used to search on GlobalID. Interestingly enough, in this particular data, I have another GUID attribute that DOES work in the Locate tool. 

So in Pro, how does one find  {09BE107D-DF2B-4FAB-A24E-02F464EDA029}? 

[JonathanFarmer_oldaccount]

Hi Tom,

I'm going to create a Support case for you to log a bug for this Locate issue. You are correct, the Locate tool will not find a GlobalID value even though that field is listed as a choice when setting up the layer. That's a bug. 

As a workaround, use Select By Attributes. It will allow you to choose that particular GlobalID value and then find it in the table and on the map for you. This works for me.

I'll reach out shortly from the case.

Jonathan

[ThomasColson · Accepted solution]

The outcome of this is to fall back to "Select by Attributes" if you're truly needing to find a row by GlobalID, and you're encountering BUG-000117511 Locate Tool in ArcGIS Pro Gives Users the Option to Search Based on GlobalID Field But Returns No Results.