How to Debug SQL Errors with AI

Begin with a reproducible case. Give the AI the database engine and version, the exact error text, the relevant query and a minimal schema. Include a few invented rows and the expected result when possible. Remove credentials and private values; a database password does not help explain a syntax error. Ask for a diagnosis before requesting a rewrite. A syntax error concerns whether the statement can be parsed. An undefined name may indicate a spelling, alias, schema or quoting problem. A type error can point to an invalid operation or conversion. Different causes need different evidence, so repeatedly asking the AI to try another query is an inefficient debugging strategy. The reported error location is a useful starting point, not proof that the marked token caused the problem. An earlier missing comma or unmatched parenthesis can make a later token unexpected. Inspect the surrounding expression and simplify the query until the failure is isolated. Grouping errors deserve a semantic decision. Adding every selected column to GROUP BY may silence an error while changing a customer summary into one row per order date. Explain what one output row should represent, then decide which values belong in the grouping and which need an aggregate. Likewise, an ambiguous column should be qualified with the intended table alias, not resolved by choosing whichever name makes the statement run. PostgreSQL documents error categories and SQLSTATE codes that help identify the class of failure. After applying a minimal repair, compare the actual result with the fixture's expected rows, totals and null behavior. A successful execution proves that the database accepted the statement. It does not prove that the query answers the original question.