Promote selected records
In this simplified example I would select say all the houses on Main street in a two block area
The result would look something like this, showing highlighted records in a random order in the table.
Say I sorted on address then selected Promote. Promote would then move all the selected to the top of the table, and the unselected still showing but listed below the selected. Each group would be sorted by HsNo in this case. I could then scroll through the table (entire table) and look for anomalies in my selection. This was a very useful tool in AV3
Say for example you were looking for all the 6 inch and above water pipe that was NOT PVC and you set up your query like this: Size >= 6 AND Material NOT LIKE 'PVC'
In your selection is something like this:
If you sorted on Material and then promoted you could scroll through the records to find anomalies in the selected and unselected set like this!
Admittedly showing only the selected and sorting then reverse select does the same thing but this was a way to see all the records at once with selected at the top of the list.
For what it's worth, I tried mocking up something similar in Pro, just to see what it might look like.
I added the FC twice to the map:
- The first feature layer's attribute table acts as fake "promote selected records" functionality. Select records; show selected records only.
- The second feature layer is the full attribute table. All rows shown.
It was pretty cumbersome to use in practice. True "Promote Selected Records" functionality is still needed.
Here's another less than ideal workaround:
Create a query layer with a FLAG field:
select
objectid,
case when type='NT' then 1 else 0 end as flag
from
infrastr.active_transportation2. Join from the FC to the query layer via the OBJECTID.
3. Sort the attribute table by the FLAG field (descending).
Now, the the rows where type='NT' are at the top of the attribute table. Which is more or less what I wanted.
However, it's not a realistic solution:
- It's too much work to set up.
- Too cumbersome and slow to use. And the criteria is based on a SQL query, not on manual selections in the attribute table.
- The attribute table becomes buggy when the join to the query layer is set up.
- Query layers are only supported for enterprise geodatabases.
Source: Specify how nulls are sorted in the attribute table (nulls first or last)
Related:
