Data correction · SQL

Support says “some customers have no status.” Don’t fill it yet.

This walkthrough follows a common repair ticket: several customers have a blank status, and operations wants it set to active. First establish who would change and how to check the outcome. Then discuss the SQL.

The ticket: On Monday morning, support finds 12 orders stuck in an internal queue because their customers have no status. Before a reviewer approves a fix, they need three answers: the protected surface is clear, the condition selects only blanks, and a read-back can show that no blanks remain.

How this repair ticket moves

See what is off limits

Start with the blacklist. If customers or status is protected, the ticket goes back to access and data policy; changing the SQL spelling is not a workaround.

dbcli blacklist list

Check what the database actually calls it

The ticket says “customer status”; production may use another field or type. Reading the live schema blocks the most ordinary—and expensive—mistake: guessing a column name.

dbcli schema customers --format json

Preflight the UPDATE and its read-back assertion

Preflight checks that the UPDATE target matches --table, contains a WHERE clause, and uses a plain SELECT for read-back. It prints a copyable after-write command.

dbcli verify safe-backfill \
  --table customers \
  --query "UPDATE customers SET status = 'active' WHERE status IS NULL" \
  --verify-query "SELECT count(*)::int AS n FROM customers WHERE status IS NULL" \
  --expect "value == 0"

Write only after approval, then verify

Review the preflight output and execute the approved write through your team’s established authorization flow. Then run the generated command with --after-write to read back the result and write an inspectable verification artifact.

dbcli verify safe-backfill ... --after-write
dbcli verification list