We need virtual, ad hoc SQL columns in the attribute table.
Think of a field calculation, but it’s a dynamic, temporary, read-only mechanism used for one-off tabular data analysis. Takes advantage of the power of SQL; should be as easy to set up as definition queries.
The field would be set up in the feature layer properties, not as a persistent field or as a persistent object in the database. Allows editing FC fields in the same attribute table. Avoids the need to create a clunky query layer or view and then join it back to the FC. No exclusive locks or privileges required other than SELECT.
Examples:
- case when class='A' then 1 else 0 end as class_flag
- Sort the class_flag field as descending (and sort other fields too). Is a workaround for things like Promote Selected Records.
- Quickly get the total cost from a related table (1:M) using a subquery:
(select sum(cost) from budget b where p.id=b.id and year=2025)
- One-time criteria that doesn't justify a permanent field, database view, query layer, etc.
- I want to see the total right in the FC attribute table. I don't want to use a relate to point to a related table.
- case when last_edited_date is not null then 1 else 0 end as null_flag
- Lots of other scenarios.
- From LukePinner in a comment — Using read-only corporate data: concatenate two or more fields, split a field, change the case of some text values, etc. For example, relate via a composite ID field.