After an UPDATE via sql.DB.ExecContext, how do you tell the caller no row matched?

## `ExecContext` is for statements that return no rows `(*sql.DB).ExecContext(ctx, query string, args ...any) (sql.Result, error)` runs a statement — `INSERT`, `UPDATE`, `DELETE`, DDL — and returns a `sql.Result` instead of a cursor. Because there is no result set, there is no `*sql.Rows` holding a connection: the connection goes back to the pool as soon as the statement finishes. That is why using `QueryContext` for a write is a real (if mild) bug — it hands you a `*sql.Rows` you then have to remember to close. ### `sql.Result` has exactly two methods ``` type Result interface { LastInsertId() (int64, error) RowsAffected() (int64, error) } ``` Both return an error, and that is the design point candidates usually miss. `sql.Result` is implemented by the driver, not by `database/sql`, and not every database can answer either question. A driver that has no answer returns an error rather than inventing a number. So `n, err := res.RowsAffected()` needs its own error check; ignoring it and using `n` means you are trusting a zero you never verified. `LastInsertId` is the more portable-looking and less portable of the two: it is meaningful on databases with a single auto-increment concept and unsupported on others, where the idiomatic path is a `RETURNING`-style clause read back with `QueryRowContext` instead. ### Turning the count into an API answer The common handler shape is an update by id where the caller deserves to know the id was wrong: ``` res, err := db.ExecContext(ctx, "UPDATE users SET email = ? WHERE id = ?", email, id) if err != nil { return err } n, err := res.RowsAffected() if err != nil { return err } if n == 0 { return fmt.Errorf("user %d not found", id) } ``` Note that `err == nil` from `ExecContext` says only that the statement executed. An `UPDATE` whose `WHERE` clause matches nothing is a perfectly successful statement. Without the `RowsAffected` check, a `PUT /users/9999` on a nonexistent id returns `204 No Content` and the caller believes it wrote something. ### Matched versus changed The one portability caveat to state out loud: `RowsAffected` reports what the database chose to report. Some databases count rows *changed* by the statement, so `UPDATE users SET email = '[email protected]' WHERE id = 1` on a row that already holds that email reports `0` even though the row exists and the statement was correct. Other databases count rows *matched*, and report `1`. Code that maps `0` to a 404 is therefore making an assumption about the database underneath it, and that assumption should be pinned down by an integration test against the real driver rather than by reading the code. When the distinction genuinely matters, do not infer: either read the row back, or make the statement itself unambiguous (for example by including a condition that changes on every write, like an updated-at column or a version number). ### The good use of the count: optimistic concurrency The same mechanism carries a stronger meaning when the `WHERE` clause includes a version: `UPDATE docs SET body = ?, version = version + 1 WHERE id = ? AND version = ?` Here `RowsAffected() == 0` means "somebody else wrote first", and that is a conflict the caller must be told about (`409`), not a not-found. The count is the entire concurrency-control signal, and dropping it silently loses updates. ### Deletes and batches `DELETE` behaves the same way: zero affected rows usually means the row was already gone, which for an idempotent delete endpoint is a success, not a 404 — a judgment call the API contract should make explicitly rather than leaving to whichever branch happened to be written first. For multi-statement scripts, what `RowsAffected` covers depends on the driver and on whether multiple statements are even permitted on one connection; do not assume it aggregates. And note that `sql.Stmt` and a transaction handle expose the same `ExecContext` shape and the same `sql.Result`, so everything above carries over unchanged. ### What an interviewer is listening for Three things: that `ExecContext` is the no-rows path and needs no `Close`; that `RowsAffected` returns an error that must be checked because the driver may not support it; and that mapping `0` to "not found" is a decision about the underlying database's counting semantics, not a universal truth.