Keep a focused SQL debugging record ​

A useful debugging record answers four questions: what was submitted, through which interface, what happened and what should have happened. Include a minimal schema and synthetic input rows so another reader can reproduce the behavior without access to private data.

For a server failure, retain the response query ID and exact exception code. Look up recorded failures with a targeted query:

SELECT query_id, type, exception_code, exception
FROM system.query_log
WHERE query_id = 'replace-with-query-id'
ORDER BY event_time;

If there is no event, check logging settings and thresholds before concluding the request never reached the service. If it is still active, inspect system.processes; it is a separate snapshot with different timing semantics.

Change one factor at a time while narrowing the case: predicate, input row, type declaration or connection mode. Confirm that simplification still reproduces the original issue. For browser-only failures, retain status and Origin/Host details without exposing Authorization values.

Do not run an analyzed write as if it were a harmless explanation. Use read-only plans first or an intentional transaction and rollback.

See query history, active requests, HTTP and EXPLAIN.