5.5 KiB
title, description, date, author, authorLink, tags, previewImg
| title | description | date | author | authorLink | tags | previewImg | |
|---|---|---|---|---|---|---|---|
| Oops! Now You Can Roll Back Data Changes | Despite all the checks in Data Controller for SAS®, sometimes the wrong updates get approved. You can now roll back to a previous version - with full audit history preserved. | 2026-08-20 09:00:00 | Data Controller | https://www.linkedin.com/showcase/data-controller-for-sas |
|
./ctrl-z.jpeg |
Oops! Now You Can Roll Back Data Changes
Despite the MANY checks and guarantees in Data Controller for SAS®, sometimes it can happen that the wrong updates are approved and applied.
Thankfully, it is now possible to roll back data changes to a previous state.
How it works in practice
Behind the scenes, rollback is not a silent undo. It is a first-class approval workflow just like any other edit. When you choose to restore a previous version, the backend - via the %mp_stripdiffs macro - reads the MPE_AUDIT table (or a custom AUDIT_LIBDS configured for the table) and computes every difference between the current state and the version you want to go back to.
It handles all three change types:
- Deleted rows are re-inserted with their original values.
- Modified rows are reverted to their previous values.
- Added rows are marked for deletion with
_____DELETE__THIS__RECORD_____="Yes".
The computed differences are written to a new staging package in the approvals directory, complete with a CSV and a macvars.sas snapshot of the session context. A new LOAD_REF is generated, and the package is submitted via the standard %mpe_loader service - so it goes through the same edit-stage-approve workflow as any manual change.
This means the rollback itself is reviewable and approvable. Nothing is applied silently, and the full audit trail is maintained: the reversion appears as a new load reference in MPE_SUBMIT, MPE_REVIEW, MPE_DATALOADS, and MPE_AUDIT, just like any other submission.
Security and access
Not everyone can roll back everything. The %mpe_checkrestore macro enforces a strict access check before the restore service will run:
- The load must actually exist and have been loaded (no rollbacks of unapproved submissions).
- The table must be configured with an audit table.
- The user must have
EDITaccess to the target table. - If the user is not an admin, Row Level Security or Column Level Security rules on the table will block the restore.
If access is denied, the service aborts with a clear reason - no opaque errors.
What this means for compliance
Because the rollback creates a new, approved changeset rather than silently rewinding history, auditors can see exactly what was reverted, when, and by whom. The MPE_AUDIT table retains the record of every intermediate state, so nothing is ever truly lost. For tables where data integrity is critical - regulatory reporting, actuarial assumptions, steering parameters - this is the difference between "we have no idea what happened" and "here is the complete chain of custody."
This feature works for all temporal-aware load types (UPDATE, TXTEMPORAL, and BITEMPORAL) and respects SCD2 validity windows. And the whole process is built on the same open-source macro library that powers the rest of Data Controller - so you can inspect, test, and audit the code itself.
Full documentation is here: https://docs.datacontroller.io/restore/