SQL Danger Checker

About this tool

SQL Danger Checker is a static pre-flight review for raw SQL: paste one or more statements and it flags the ones that can lose or overwrite data before you run them. It never connects to a database and never executes anything — it reads the text and classifies each statement, so it is safe to run against a query you have not decided to execute yet.

It flags four kinds of destructive SQL:

• DROP DATABASE / DROP SCHEMA / DROP TABLE and TRUNCATE — critical, they permanently delete objects and every row in them.
• DROP of another object (index, view, column …) and ALTER … DROP … — high, they discard whatever the dropped object held.
• Other ALTER schema changes — medium, review and back up first.
• UPDATE / DELETE with no WHERE — or a trivially-true one such as WHERE 1=1 — high, because they touch every row in the table.

Worked example

Paste:

DROP TABLE users;
DELETE FROM sessions;
UPDATE accounts SET balance = 0;
SELECT * FROM orders WHERE id = 42;

and you get a report like:

3 danger(s) found (1 critical, 2 high, 0 medium, 0 low) in 4 statement(s) scanned

statement 1, line 1  CRITICAL  DROP-TABLE  DROP TABLE permanently removes the table and all of its data.
  DROP TABLE users;

statement 2, line 2  HIGH  DELETE-NO-WHERE  DELETE without a WHERE clause removes ALL rows in the table.
  DELETE FROM sessions;

statement 3, line 3  HIGH  UPDATE-NO-WHERE  UPDATE without a WHERE clause overwrites ALL rows in the table.
  UPDATE accounts SET balance = 0;

The SELECT is left alone. Each finding gives the statement number, line, severity, a rule id, and the offending statement so you can jump straight to it. Choose JSON output to pipe the same findings into a script or CI check.

Options and limits

Set a dialect (MySQL additionally treats # as a line comment); raise the minimum severity to hide low-risk findings; turn on strict to also surface guarded DELETE/UPDATE (the ones that already have a real WHERE) as a low "confirm before running" note; and use allow to suppress categories you know are intentional (for example drop, truncate in a migration).

This is a heuristic, not a SQL parser. It splits statements on ; and masks comments and string/identifier literals so a DROP inside a -- comment or a 'string' is ignored and a ; inside a string does not split a statement — but it does not understand stored procedures, dynamic SQL built at runtime, MERGE, or a WHERE that is technically present yet still matches every row. Treat findings as leads to review, not a guarantee, and always test destructive SQL inside a transaction with a backup.

FAQ