Debug a failing query with Claude.

Before you start

You need a query that's actually failed, an Anthropic (or other provider) API key added in Settings, and the connection that produced the error still selected. This works on any of the nine connectors.

Step by step

1. Run the query that failed in the SQL Editor.
2. Click Ask (or ⌘L) to open the panel.
3. Attach Last error so Claude sees the actual error text, not a paraphrase.
4. Ask a specific question, like “why did this fail” or “fix this query.”
5. Review the corrected SQL, then Insert into editor or Run it directly.

A worked example: a Databricks catalog mismatch

Say a query against a Databricks warehouse fails with [TABLE_OR_VIEW_NOT_FOUND] Table or view 'orders' cannot be found, because the query used a bare table name instead of the full catalog.schema.table path. Attach Last error and ask for a fix. A reasonable response points out the missing qualifiers and corrects it to:

SELECT *
FROM main.sales.orders
LIMIT 100;

along with a short explanation that Databricks needs the catalog and schema unless a default is set on the connection.

Check it worked

Run the corrected query. If it returns rows without an error, you're done. If it fails again with a different error, attach that new error and ask again, most fixes need one round, some need two if the first error was masking a second problem underneath.

Troubleshooting

What this doesn't replace

It's not a substitute for connection-level troubleshooting. If nothing you write succeeds, the problem is more likely the connection than any individual query, see database connection failed, how to actually fix it instead.

A worked example: a Postgres permissions error

A query fails with permission denied for table customers. Attach Last error and ask what happened. The panel explains that this is a grants issue, not a syntax problem, and that the role running the query needs SELECT on that table, it can't grant the permission itself, but it saves you from assuming the query is wrong when the connection's role is what actually needs fixing.

Debugging results, not just errors

Attach a query's result set instead of an error and ask "does anything here look wrong" after a query that ran successfully but returned numbers that seem off. This catches logic errors, a JOIN that's silently duplicating rows, a date filter off by a day, that don't throw an error at all but still produce a wrong answer.

A third worked example: a silent duplication

A query joining orders to order_items without aggregating first returns a revenue total that's obviously too high. Attach the result and ask what looks wrong; the panel notices the row count is larger than the order count and flags the missing GROUP BY or the need to aggregate items before joining, a bug that would never throw an error on its own.

Debugging across dialects

The same workflow applies whether the failure came from Postgres, Snowflake, BigQuery, or Databricks. A BigQuery job failing on a result over 25 MB with no LIMIT gets a fix that adds one; a Databricks Unity Catalog permissions error gets pointed at the missing grant rather than treated as a syntax problem.