SQL Query Generator
Build SELECT, INSERT, UPDATE, DELETE queries visually. Now with ORDER BY, LIMIT, and INSERT/UPDATE values.
Writing a query when SQL is not your daily language
Describe what you need in plain English and get a SELECT, INSERT, UPDATE or DELETE statement back. The common situation in testing is that you know exactly what you want to check, the orders created today that have no payment record, and reaching for the right join syntax takes longer than the check itself.
Treat the output as a first draft. It is generated from your description, not from your schema, so the table and column names are guesses based on what you wrote. Read it before running it, and never run a generated statement against production without reading it twice.
Verifying data after a test
A user interface assertion tells you what was displayed. A database query tells you what was stored, and the two disagree more often than people expect. Checks worth making directly against the database after a functional test:
- The record exists exactly once: a retried request that created two rows is invisible in the interface.
- Optional fields are null rather than an empty string, or the other way round, matching whatever the specification says.
- Timestamps are stored in UTC and not in the server’s local time.
- A soft-deleted record is flagged rather than removed, if that is the design.
- Related rows were written: an order without its line items is a partial-failure bug.
- Numeric values kept their precision, particularly money stored as a floating point type.
The two clauses that cause accidents
An UPDATE or DELETE without a WHERE clause applies to every row in the table. This is the classic way a test environment is destroyed, and occasionally a production one. Two habits prevent it: write the statement as a SELECT first, confirm the row count is what you expected, and only then change the verb. And run inside a transaction where your client supports it, so a mistake can be rolled back.
The second trap is NULL comparison. A value that is NULL is not equal to anything, including another NULL, so WHERE status = NULL matches no rows and raises no error. The correct form is IS NULL. A query silently returning nothing is the usual symptom.
Joins, briefly, for testers
| Join | Returns | Typical QA use |
|---|---|---|
| INNER | Rows matching on both sides | Orders that do have a payment |
| LEFT | All left rows, matched or not | Orders with no payment: filter where the right side IS NULL |
| RIGHT | All right rows | Rare; usually a LEFT join written backwards |
| FULL OUTER | Everything from both sides | Reconciling two systems that should agree |
The orphan-record check, a LEFT join filtered to where the joined side is NULL, is the single most useful query pattern in data testing. It finds exactly the records that should have a counterpart and do not.
Generated SQL is not a substitute for parameterised queries
Worth stating clearly. A statement produced by concatenating text is fine for a manual check you are about to read and run yourself. It is not acceptable in application code, where user input must go through bound parameters: that is what prevents SQL injection, and no amount of escaping by hand replaces it. If you find application code assembling SQL by string concatenation with user input, that is a finding regardless of how carefully it appears to be escaped.
Generation runs in your browser, so a description that mentions real table names from an unreleased schema is not sent anywhere.
Frequently asked questions
Why does my WHERE clause return no rows when the value is null?
Because NULL is not equal to anything, including another NULL. Use IS NULL or IS NOT NULL. The comparison form fails silently, which makes it a common cause of a test that passes because it checked nothing.
How do I find records that have no matching row in another table?
Use a LEFT JOIN and filter to where a column from the joined table IS NULL. That returns exactly the orphans, orders without payments, users without profiles, and it is the most useful single pattern in data testing.
What is the difference between DELETE, TRUNCATE and DROP?
DELETE removes rows and can be filtered and rolled back. TRUNCATE removes all rows quickly and usually cannot be rolled back or filtered. DROP removes the table itself. In a shared test environment, know which one you are about to run.
Is generated SQL safe to run against production?
Read it first, every time. It is generated from your description rather than from your schema, so table and column names are inferred. Run SELECT statements freely, and treat anything that modifies data as something to review, wrap in a transaction, and preferably run somewhere else first.
Does this replace parameterised queries in application code?
No. Generated text is for manual checks. Application code must bind user input as parameters, which is what actually prevents SQL injection. Code that concatenates user input into a statement is a finding no matter how it is escaped.
Which SQL dialect is produced?
Standard SQL that works across common databases for ordinary statements. Dialects diverge on date functions, string concatenation, pagination syntax and quoting, so verify anything non-trivial against the database you are actually using.