Merge pull request 'feed: add a who-is-it-for post for Data Controller' (#22) from feed/who-is-data-controller-for into main

Reviewed-on: #22

content/blog/two-rule-sets-one-table/index.md

@@ -41,16 +41,31 @@ libname ORDERS_US '/data/orders';
 
 ![The second report accepts the same value](rule-set-2.png)
 
-Everything else works exactly as it always did. Filtering, search, the row cap, the approval diff and the audit trail all operate on the table as normal, because as far as Data Controller is concerned these are ordinary tables. The only difference is that the two names resolve to the same file, so an approval in either report updates the same data.
+Everything else works exactly as it always did. Filtering, search, the row cap, the approval diff and the audit trail all operate on the table as normal, because as far as Data Controller is concerned these are ordinary tables. The only difference is that the two names resolve to the same file, so an approval in either report updates the same data - and that one difference has a consequence for concurrency, which is covered below.
 
 There is no copy to keep in sync, no hook to write and nothing to maintain. That is why it is the option we recommend.
 
 ### Things worth knowing
 
 - Where the librefs are defined depends on your platform. On Viya, in the compute context's `autoexec.sas` (or `[DC Drive Path]/services/settings.sas`); on SAS 9, as metadata libraries or in the Data Controller Settings stored process; on SASjs Server, in `services/public/settings.sas`. The one requirement is that each library has a unique libref.
-- `mp_lockanytable` keys on `libref.dataset`, so the two menus do not serialise against each other. Two people editing through different reports at the same moment can therefore collide at the database level. If that matters, add an explicit shared lock in a `PRE_APPROVE_HOOK`.
+- `mp_lockanytable` keys on `libref.dataset`, so the two menus do not serialise against each other. That has consequences beyond a collision - see *The concurrency caveat* below.
 - The audit trail and approval queue record which libref a change came through, so `ORDERS_EU.ORDERS` and `ORDERS_US.ORDERS` stay distinguishable in history. For most people that is a feature - you can see which report a change originated from.
 
+### The concurrency caveat
+
+Data Controller serialises its writes with `mp_lockanytable`, and the control table it uses, `MPE_LOCKANYTABLE`, has a primary key of `(lock_lib, lock_ds)`. That is the *registration*, not the physical file. At approve time, `postdata` takes the lock on the base table named in the submit record, and the same service runs its "has this table been updated since the diff screen was shown" check against `MPE_DATALOADS`, keyed on that same `libref` and `dsn`.
+
+Two librefs over one location are two different `(libref, dsn)` pairs, so:
+
+- two approvals arriving through different reports take two different locks, and neither one blocks the other;
+- a load through one report writes its `MPE_DATALOADS` entry against its own name, so the other report's staleness check does not see it either.
+
+So two people editing the same rows through different reports can both be approved, and the second write wins, silently. The lock is advisory to begin with - `mp_lockanytable` is, in its own words, "only useful if every update uses the macro" - so this is not a new class of risk, but registering one file twice is a new way to fall into it.
+
+The hook route does not have this problem. Both mirrors route their submit to the same base table, so every approval locks, loads and logs against one identity.
+
+If you do use two librefs, and concurrency matters to you, the cleanest fix is to keep the two registrations for the edit screen and give each one a `POST_EDIT_HOOK` that re-points the changeset at a single canonical registration - then every approval is keyed on the same table regardless of which report raised it. Register that canonical name as well. The alternative, an explicit shared lock taken in `PRE_APPROVE_HOOK` and released in `POST_APPROVE_HOOK`, works too, but a failed run leaves the sentinel locked and `MPE_LOCKANYTABLE` is then a table you have to unpick by hand.
+
 ## Option 2: an empty mirror and a pair of hook scripts
 
 Sometimes two librefs over one location are not available: a database library where the platform will not let you define the same object twice, or a site where adding a library definition is a change nobody wants to make. Then you can reach the same result with a mirror table and two hook scripts.
@@ -99,6 +114,7 @@ Use `call symputx`, not `%let`. `LIBREF` and `DS` are not declared `%local` in `
 
 ### Other things to watch
 
+- Concurrency behaves correctly here. Both mirrors route their submit to the same base table, so every approval locks, loads and logs against one identity - unlike the two-libref route above.
 - The filter has already been applied to the empty mirror by the time the pre-edit hook runs, so a hook that reads the real table ignores the user's filter unless it re-applies it (`where %inc filtref`). On a small table you will not notice; on a large one the `DC_MAXOBS_WEBEDIT` cap will stop the edit screen with "Table is too big".
 - The hook's output must have the same columns the editor expects - the real table, minus any transaction or processing columns that Data Controller drops on load.
 - The real table must itself be registered in `MPE_TABLES`. The approval screen resolves the table's audit settings from that row, so a changeset routed to a table with no registration cannot be reviewed - the submit is refused up front, naming the table.

content/feed/who-is-data-controller-for/index.md

@@ -0,0 +1,74 @@
+---
+title: 'Data Controller for SAS® - Who Is It For?'
+description: Five roles, five questions - what Data Controller for SAS® answers for administrators, auditors, managers, data owners and purchasers.
+date: '2026-09-26 09:00:00'
+author: 'Data Controller'
+authorLink: https://www.linkedin.com/showcase/data-controller-for-sas
+tags:
+  - Announcements
+previewImg: './who-is-data-controller-for.jpeg'
+---
+
+# Data Controller for SAS® - Who Is It For?
+
+Data Controller for SAS® gives business users a safe way to add, modify and delete data in SAS tables and databases, without handing them write access to production. That one capability answers a different question for each role that touches the data - so here is the short version, role by role.
+
+## Data Administrators
+
+Would you grant self-serve data updates in SAS if there was no risk to the data model? That is the trade Data Controller offers. End users never get direct write access to the target tables - every change is staged, validated at the point of entry, and applied by the service itself. Data Controller changes data, not structure, so your data model stays as it is.
+
+## Data Auditors
+
+Do you need to know who made a particular data change, what that change was, when it was made, and who signed it off? Every submission carries a full audit trail, and any associated Excel file is retained alongside it, so the source of a change can be reviewed long after it was loaded.
+
+## Data Managers
+
+Do you want to load, modify or delete production data without writing repetitive code, saving sensitive data to shared filesystems, building and deploying jobs, or crafting long-winded change requests? Adding a new editable table is configuration rather than development - the grid is generated from the target table's metadata, and the load type (composite or retained keys, SCD2, bitemporal) is picked from a list.
+
+## Data Owners
+
+Do you like to review data changes before they are applied? Approvers see the diff - new, changed and deleted rows - and nothing lands until it is signed off. Email alerts can tell you when data is changed or about to change, and a completed load can trigger a SAS job downstream. If the wrong change gets approved anyway, the table can be rolled back to a previous state - and the rollback is itself a new, reviewable change, so the audit trail keeps both the mistake and the correction.
+
+## Purchasers
+
+How about a business friendly, no lock-in software licence? The price list is public, every package includes unlimited users, and a perpetual licence is available. The Community package is free, so evaluating Data Controller costs nothing but the installation.
+
+## What it is, in one line
+
+Data Controller for SAS® is a robust solution for secure data uploads into any SAS-connected database, with full audit trail and approval mechanism. Configuration is quick, installation is easy, and everything runs on your own SAS platform with no external calls.
+
+Multiple load types are supported (composite and retained keys, SCD2, bitemporal, format catalogs), data can be validated at the point of entry, and Excel end-user computing files can be dragged straight into SAS. Data Lineage, Data Catalog and Data Viewer come as standard.
+
+Data Control.
+
+Want to see it working on your own data? [Book a Discovery Call](/contact).
+
+<!--
+Source LinkedIn post:
+
+Data Administrators - would you grant self-serve data updates in SAS, if there was no risk to the data model?
+
+Data Auditors - do you require oversight of who made a particular data change, what that change was, when it was made, and who signed it off? And to review the original excel, if used as a source?
+
+Data Managers - do you prefer to load / modify / delete production data WITHOUT writing repetitive code, saving sensitive data to shared filesystems, building & deploying jobs, or crafting long-winded change requests?
+
+Data Owners - do you like to review data changes before they are applied? How about receiving email alerts or the ability to set up job triggers after tables are updated?
+
+Purchasers - how about a business friendly, no lock-in software licence?
+
+Data Controller for SAS® is a robust solution for secure data uploads into any SAS-connected database, with full audit trail and approval mechanism.
+
+Installation is easy and configuration is quick. Multiple load types supported (composite / retained keys, SCD2, Bitemporal, Format catalogs). Perform data validation at point of entry. Drag & drop Excel EUCs straight into SAS.
+
+Data Lineage, Data Catalog, Data Viewer.
+
+Data Control.
+
+#sas #sasviya #sasusers #datagovernance
+
+https://lnkd.in/dunqWhnt
+
+Image prompt:
+
+Flat vector illustration, dark slate blue background (#314351), wide 1.91:1 banner (1200 x 627). Five simplified human figures stand in a shallow arc across the centre, each rendered in flat corporate style with minimal facial detail: an administrator beside a padlock, an auditor with a magnifying glass over a document, a manager holding a spreadsheet with an upward arrow, a data owner holding an approval tick, and a purchaser holding a price tag. Behind them, a translucent dashboard panel shows a data grid with one row highlighted as a pending change, and a small diff of new, changed and deleted rows. Thin connecting lines link each figure to the panel, suggesting that every role sees the same controlled workflow. Bright green accent (#90c445) used sparingly on the approval tick, the highlighted row and the connecting lines. Subtle depth with soft shadows, crisp edges. No text, no words, no letters, no logos, no watermarks. Keep the figures and the panel inside the central square so the image is safe to crop to 1:1 - the outer left and right thirds are background only.
+-->