Popups: Sort related records?

246
6
Jump to solution
a month ago
AlfredBaldenweck
MVP Regular Contributor

I have a point feature class which participates in a 1:M relationship with a table.

The popup is set up to show the related table.

AlfredBaldenweck_1-1713972063480.png

The issue is that the records are displayed according to OBJECTID (That is, the record for 2012 was created before the record for 2011). 

AlfredBaldenweck_3-1713972151436.png

Is there a way return the related records sorted by another field?

1 Solution

Accepted Solutions
Scott_Harris
Esri Regular Contributor

You might want to experiment with the commands found here:

Scott_Harris_0-1714055452139.png

 

The sort order seems to be remembered for me when re-opening the project.

View solution in original post

0 Kudos
6 Replies
Bud
by
Notable Contributor

If you submit an idea for this, I’d vote for it.

0 Kudos
Bud
by
Notable Contributor

Could you create a query layer or database view, and do this in the SQL?

  • Use ORDER BY to sort on the required field. Do this in an subquery (inner query). Exclude the OBJECTID column from the SELECT clause.
  • In an outer query, generate a fake OBJECTID column using a mechanism like Oracle’s ROWNUM pseudocolum, or your database’s equivalent.
  • Use the fake OBJECTID as the unique ID in the query layer or database view in Pro.

Maybe Pro would sort on the fake OBJECTID column in the popup, which is the sort order you wanted: sorting on your other field.

 

0 Kudos
AlfredBaldenweck
MVP Regular Contributor

I'm sure it should be possible, but here are two pretty big issues:

  1. Waaay more work than I want to take care of
    1. Query layers are a pain, and we both know the current way to set up views is horrible given how plain the text editor is in CreateView()
  2. Only solves the issue for GDB feature classes*; you couldn't do it in a shapefile, for example. In this case, I'm using a relationship class; frequently it's just using a relate.
    1. Actually, the Query Layer part is only useful for eGDBs
    2. fGDBs can take care of Views, at least, but see point #1.

I think for a more permanent dataset, like the one in my example (which does actually live in an eGDB), a view or query layer would probably do the trick the way you outlined it (Will probably give it a shot later today). But the goal is to just have this out of the box.

 

*Esri I know it's 20 years too late but please give us an easy vocabulary word for feature classes in geodatabases. I like "GDBFC" since it kind of rolls off the tongue and then you and prefix it with what type of GDB it is --> fGDBCFC, eGDBFC, etc. Either way, the lack of a decent vocabulary word is keenly felt; everyone keeps calling all vector data a shapefile (it's not) or a layer (definitely not), or just plain "geodatabase" (ABSOLUTELY NOT) and it makes having a conversation with users really hard because I have to figure out what they actually mean when they say a word.

0 Kudos
Scott_Harris
Esri Regular Contributor

You might want to experiment with the commands found here:

Scott_Harris_0-1714055452139.png

 

The sort order seems to be remembered for me when re-opening the project.

0 Kudos
AlfredBaldenweck
MVP Regular Contributor

That appears to have worked and I think I can save it as a layer file.

The sort Asc/Desc appears to be dependent on the display settings in the layer/view, so by editing that you can pick which field(s) to sort by. Thanks!