How to restore rows after UPDATE or DELETE in Rowset Studio
A practical look at pre-write row backups, post-commit Restore, and the cases where you should pause.
A concrete mistake
Suppose you meant to change one order. The statement is valid SQL, but the condition matches every pending order. A transaction Rollback helps only while that transaction is still open.
UPDATE orders
SET status = 'shipped'
WHERE status = 'pending';SELECT id, total, status FROM orders WHERE customer_id = 1001 LIMIT 100;
What Rowset saves before the write
With row backups enabled, Rowset reads the rows matched by an eligible UPDATE or DELETE and saves their prior values before executing the change. The backup is tied to the actual operation, rather than a separate full-database dump.
After Commit, open Activity → Row backups. You can use Restore or open the generated restore statements in a new editor tab for review. Restore is distinct from transaction Rollback: it acts on saved row values after the original write has completed.
Review before restoring
For an UPDATE backup, Restore writes saved values back to matching rows. For a DELETE backup, it inserts saved rows again. If someone has edited those rows since your original write, restoring may overwrite their later changes, so inspect the target first.
SQL row backups apply to eligible single-table UPDATE or DELETE statements with a WHERE clause, up to 10,000 affected rows. UPDATE needs a primary key. Joined and multi-table writes may not qualify; Rowset asks before continuing without a backup when it cannot make one.
SELECT id, status, updated_at
FROM orders
WHERE id IN (3001, 3004, 3007);