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?
Solved! Go to 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.
Hi Tom,
I just tested this on my end with Pro 2.2.3 and I can sort both ascending and descending using the GlobalID field on a feature service.
What happens when you try to? An error? Or is the option grayed out?
Jonathan
Data source is SQL 2014 ENT, Geography Storage Type, no SQL triggers or alteration to GlobalID default (Should be a class 4 GUID?), 10.6.1 feature service. Doesn't sort as a feature service, sorts as a .geodatabase.....
Is the feature class registered with SDE or is it a query layer from a SQL 2014 database that is spatially enabled but not registered with SDE?
What version of Pro is this Tom? Because all my specs match yours except I'm running SQL 2016.
2.2.1, plain-vanilla SDE feature class, not a view, not a query. Everything in this workflow is out of the box. We have not certified 2.2.3 for use (security and regression testing), and likely won't any time soon. I should add, being off-line capable, the feature class is archived, but not registered as versioned. Editor tracking. Storage type geography, GCS NAD83. Here is a public copy of one of the FC's that's not sorting, but the GlobalID's will be different: http://www.arcgis.com/home/item.html?id=2d413fce1dc349bd92af8fdcdbe8c3c9
Sure wish there was a GUID validator in Pro...https://community.esri.com/ideas/14489 . I have had mixes of different types of GUID's cause GIS processes to fail in the past.
Tom,
I just took the URL for this data and added it to Pro. In both 2.2.3 and 2.2.1 on my end, it will sort by GlobalID both ascending and descending.
If I sort ascending, I get:
{a8cc2e69-4148-4ae9-9861-00594bbaa163} |
If I sort descending, I get:
{064308cd-9f49-4cf1-bb9c-ff4b299139e9} |
It is hard to tell from the gif exactly what you see on your end but I take it these results aren't it?
Jonathan
Nope, the AGOL Feature Service, as well as the Server 10.6.1 Feature service, does not sort on GlobalID. Happens with 100% of my feature services, on multiple installs of 2.2.1. We may be defining "Sort" differently (Alberto Ferrari : How are GUIDs sorted by SQL Server? ). When the feature service is online, I get the same results you do. When I download it to a .geodatabase, I get:
And:
Note how the sorting is occurring on
0 1 2 3 4 5 6 7 8 9 A B C D E F
...and looking at the AGOL version of the data I posted, I can sort the GlobalID in Arc Map, as in the two images above, without having to take it offline. Interestingly, in both Pro and Arc, when online, the feature service Globalids are rendered in lower case, when offline....upper case, however, Pro is missing the Arc Map functionality to be able to sort the GlobalID while online.
Thanks for the additional information Tom. I see the issue now. When you stated things weren't sorting, I figured they weren't sorting at all. But the behavior is different in Pro when online vs. off compared to ArcMap.
I see what you do. Let me look into this some more and I can get back with you.
Jonathan