Section 1 of 3 · 6 minutes
Find the exact rows before changing them
Your goal
What you will be able to do
Use a read-only query to identify and count every row a change would affect.
Why this matters at work
The practical reason
An UPDATE or DELETE without the right filter can change far more data than intended.
Learn
The idea in plain English
Write the SELECT form of a change first. Use the same WHERE clause you plan to use for UPDATE or DELETE. Read the rows and count them before you make the change.
Include a stable identifier in the result. If the expected set is small, compare the identifiers with the request or incident record. Do not rely only on a total count.
Remember these points
- Test the exact WHERE clause with SELECT first.
- Return stable row identifiers for review.
- Stop when the result does not match the intended scope.
See it in SQL
Preview invalid account statuses
Identify exactly which rows need correction before an UPDATE.
SELECT account_id, account_status
FROM training_accounts
WHERE account_status NOT IN ('active', 'paused', 'closed')
ORDER BY account_id;The predicate defines invalid values explicitly. Ordering by the stable account ID makes the review repeatable.
Use the same predicate inside the later UPDATE. If new invalid rows appear between review and change, the transaction strategy must account for that.
Only accounts whose status is outside the approved set, ordered by account ID.
Useful words
Important terms
- Predicate
- The condition, usually in a WHERE clause, that selects rows.
Quick check · Not graded
Check your understanding
What is the safest first step before a production UPDATE?
Your progress is saved to your signed-in account.