Data Manipulation Language changes what is in your tables. Run INSERT, UPDATE and DELETE against a live table, watch every affected row light up, and use a transaction to undo the damage.
DML (Data Manipulation Language) includes statements that insert, update, and delete rows. INSERT adds data, UPDATE changes selected rows, and DELETE removes selected rows. SELECT is often taught alongside DML, though SQL classifications vary.
The WHERE clause limits which rows change. Before running a broad update or delete, run an equivalent SELECT with the same predicate and inspect the rows. A missing WHERE can change or delete every row.
When several statements must succeed together, use a transaction: begin, perform the changes, then commit only when the required conditions hold. Roll back when any step fails. The exact syntax and error recovery behavior are engine-specific; see transactions and ACID.
For an operation that inserts a row or updates it on a key conflict, many engines provide an upsert syntax. Names and semantics differ (ON CONFLICT, ON DUPLICATE KEY, or MERGE), so consult the target engine. Make the conflict key explicit and consider whether a retry can duplicate an external side effect.
Large changes can hold locks, generate substantial logs, and affect replication. Batch them only when the batches preserve the intended transaction semantics. Record how many rows changed and verify important invariants afterward. Use bound parameters for values supplied by users; see SQL injection prevention.
For a critical update, check both the predicate and the number of affected rows. An update expected to change exactly one account should fail safely if it changes zero or several rows. Use a transaction when the count must be checked before commit. For deletion, decide whether records should be physically removed or retained with a status and audit trail; soft deletion changes every query that must hide inactive rows. See WHERE for predicate behavior.
A read followed by a write can race when two clients act at once. For inventory, subtract one only where the current quantity is positive, then check that exactly one row changed. The database evaluates the predicate and update as one statement, avoiding an application-level gap between the check and the write. If several tables must change together, put those statements in a transaction. The correct isolation and locking strategy still depends on the database and the rest of the workflow.
About to run: set Raise salary by to its maximum (50). Before it does — what happens to the readout?
Committing to an answer first is the point — the reveal runs the experiment on the visualisation above and reads the real value back, so nothing here is scripted.
Say the answer out loud before you reveal it — recalling it is what makes it stick, and rereading it is not.
What does this module say about “The commands that change rows”?
What does this module say about “Make multi-step changes atomic”?
What does this module say about “Bulk changes and safety”?
Run INSERT, UPDATE, DELETE and SELECT on a live table and see why a missing WHERE clause can wipe every row in one statement.