Adds a feed post explaining how to run more than one set of validation rules against a single physical table.
Structure
Why one table is one rule set - MPE_TABLES is keyed (tx_from, libref, dsn) and MPE_VALIDATIONS on (tx_from, base_lib, base_ds, base_col, rule_type), so rules hang off the physical table with no per-menu or per-report scoping.
Option 1 (recommended): two librefs over the same data - configuration only. Both names are the same file, so an approval in either report updates the same data, and filtering, search, the row cap, the diff and the audit trail are untouched. Includes the platform-specific place to define the librefs and the locking / audit caveats.
Option 2: an empty mirror plus two hook scripts - the deep dive. PRE_EDIT_HOOK replaces work.OUT so the empty mirror shows live rows; POST_EDIT_HOOK reassigns LIBREF / DS at submit time so the changeset is raised against the real table. Covers the call symputx vs %let trap, the already-applied filter, the column shape, and the config that has to stay in step between the two MPE_TABLES rows.
Four screenshots, all taken on the demo estate with a synthetic orders table:
rule-set-1.png / rule-set-2.png - the same amount (5000) rejected in one report and accepted in the other
mirror-live.png - an empty mirror displaying the live rows of its target table
approval-routed.png - a change submitted against the mirror, raised against the real table
Every claim was checked against the source (mpe_tables.ddl, mpe_validations.ddl, getdata.sas, mpe_loader.sas, postdata.sas) and the behaviour was reproduced on a live Viya estate before writing it up.
Adds a feed post explaining how to run more than one set of validation rules against a single physical table.
## Structure
1. **Why one table is one rule set** - `MPE_TABLES` is keyed `(tx_from, libref, dsn)` and `MPE_VALIDATIONS` on `(tx_from, base_lib, base_ds, base_col, rule_type)`, so rules hang off the physical table with no per-menu or per-report scoping.
2. **Option 1 (recommended): two librefs over the same data** - configuration only. Both names are the same file, so an approval in either report updates the same data, and filtering, search, the row cap, the diff and the audit trail are untouched. Includes the platform-specific place to define the librefs and the locking / audit caveats.
3. **Option 2: an empty mirror plus two hook scripts** - the deep dive. `PRE_EDIT_HOOK` replaces `work.OUT` so the empty mirror shows live rows; `POST_EDIT_HOOK` reassigns `LIBREF` / `DS` at submit time so the changeset is raised against the real table. Covers the `call symputx` vs `%let` trap, the already-applied filter, the column shape, and the config that has to stay in step between the two `MPE_TABLES` rows.
Four screenshots, all taken on the demo estate with a synthetic orders table:
- `rule-set-1.png` / `rule-set-2.png` - the same amount (5000) rejected in one report and accepted in the other
- `mirror-live.png` - an empty mirror displaying the live rows of its target table
- `approval-routed.png` - a change submitted against the mirror, raised against the real table
Every claim was checked against the source (`mpe_tables.ddl`, `mpe_validations.ddl`, `getdata.sas`, `mpe_loader.sas`, `postdata.sas`) and the behaviour was reproduced on a live Viya estate before writing it up.
hermes
changed title from feed: add a post on running two rule sets against one table to blog: add a post on running two rule sets against one table2026-09-24 15:38:41 +00:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Adds a feed post explaining how to run more than one set of validation rules against a single physical table.
Structure
MPE_TABLESis keyed(tx_from, libref, dsn)andMPE_VALIDATIONSon(tx_from, base_lib, base_ds, base_col, rule_type), so rules hang off the physical table with no per-menu or per-report scoping.PRE_EDIT_HOOKreplaceswork.OUTso the empty mirror shows live rows;POST_EDIT_HOOKreassignsLIBREF/DSat submit time so the changeset is raised against the real table. Covers thecall symputxvs%lettrap, the already-applied filter, the column shape, and the config that has to stay in step between the twoMPE_TABLESrows.Four screenshots, all taken on the demo estate with a synthetic orders table:
rule-set-1.png/rule-set-2.png- the same amount (5000) rejected in one report and accepted in the othermirror-live.png- an empty mirror displaying the live rows of its target tableapproval-routed.png- a change submitted against the mirror, raised against the real tableEvery claim was checked against the source (
mpe_tables.ddl,mpe_validations.ddl,getdata.sas,mpe_loader.sas,postdata.sas) and the behaviour was reproduced on a live Viya estate before writing it up.79dd7be3fftod03afdd459feed: add a post on running two rule sets against one tableto blog: add a post on running two rule sets against one tabled03afdd459tocddf750dffcddf750dffto1ae06572c91ae06572c9to35c60941da35c60941datoa1513b871e