2026-10-21 22:26:31 +00:00
4 changed files with 33 additions and 0 deletions
@@ -12,6 +12,39 @@ Derived variables are useful when users need to work with a value that is a func
 The values are **not stored**. They are computed on every read, and nothing derived is written back when a change is submitted or approved.
 ## What it looks like
 The table below is shown in the EDIT screen. `LINE_VALUE` is `QTY * PRICE` and `REGION` is derived from `STATE`; neither exists in the table itself, and both are read-only.
 ![](./img/derived-grid.png)
 Because the derived columns are created before the filter is applied, they can be filtered like any other column. Here `REGION = 'West'` selects the two western states, and the filter bar names the derived variable:
 ![](./img/derived-filter-region.png)
 A numeric derived column works the same way - `LINE_VALUE > 50` leaves the one row that satisfies it:
 ![](./img/derived-filter-value.png)
 ## How it works
 The statements are written into a DATA step view over the target table, and the filter is applied to that view rather than to the table:
 ```sas
 data work.vw_derived / view=work.vw_derived;
  set &libds;
  attrib REGION length=$8 label='...' format=$8.;
  REGION = ifc(STATE in ('CA','OR','WA'),'West','East');
 run;
 data out;
  set work.vw_derived;
  where %inc filtref;;
 run;
 ```
 A `WHERE` statement applies to the data set named on the `SET` statement, so in a single step it cannot see a variable created later in the same step. Putting the derived variables on the view means they are on the input to the step that filters, which is what makes them filterable at all.
 ## Configuration
 Derived variables are configured per table in the [MPE_DERIVED](/tables/mpe_derived/) control table, which is itself a Data Controller table - so it is maintained through the EDIT screen with the usual review and approve workflow.