Indentation can make a long query easier to inspect, but formatted SQL is still only text. A formatter cannot determine whether a query returns the right rows, exposes sensitive data, or changes the database safely. Treat formatting as one part of review.
Make the query readable, then trace it
The Toolsnix SQL Formatter can normalize whitespace and help separate clauses. After formatting, identify the tables, joins, filters, grouping, ordering, and limit. Compare each part with the request the query is meant to answer.
For a SELECT, check whether joins multiply rows, whether an outer join was accidentally made restrictive by a WHERE condition, and whether filters cover the intended tenant or account. For UPDATE and DELETE, inspect the WHERE clause carefully and verify the affected row count in a safe environment before committing. Do not run an unfamiliar destructive query against production as a test.
Check values and permissions
Values from users or other untrusted sources should be passed through parameterized queries supported by the database driver. Do not build SQL by concatenating user input into the query string. Parameters generally represent values, not table or column identifiers; dynamic identifiers need a strict allowlist and correct quoting for the database.
Review the account that will execute the statement. Give an application account only the database permissions it needs. A read-only query can still disclose data if it selects too many columns or omits an access filter.
Use a safe review sequence
- Format the query and identify every table and operation.
- Compare conditions and joins with the intended business rule.
- Check parameters, access scope, and permissions.
- Run a read-only preview or explain plan when appropriate.
- Test writes in a disposable or staging database, inspect affected rows, and use a transaction or backup strategy suited to the operation.
FAQ
Does formatting prevent SQL injection?
No. Use parameterized queries and safe handling of dynamic identifiers. Formatting does not change how values are constructed.
Can I trust a query because it runs successfully?
No. A query can execute and still return incorrect data or modify too many rows. Compare results with expected cases.
Should generated SQL be run directly?
Review it first, and test against a safe database with appropriate permissions. Never paste sensitive production data into an untrusted service.