Free tools Windows power users keep installed
One-click scans. No signup required.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Do not trust an AI-generated SQL result just because the query runs. Treat the SQL as a draft: define exactly what you need, inspect the query’s logic, compare its output with an independent reference, and limit what it can do. Microsoft warns that generated queries may be inaccurate or return results the user did not intend; Databricks likewise notes that successful execution does not establish correctness.
Turn the request into a testable specification
Before reviewing SQL, make the business question precise enough to check. Identify four things: the population being counted, the measure, the time range, and the output grain—the level represented by each row.
- Population: Which records or entities belong in the answer? State exclusions such as canceled orders or test accounts.
- Measure: Define the calculation, including what counts as revenue, an active customer, or a completed order.
- Time range: Give the start and end dates and specify which date field governs inclusion.
- Grain: Say what one output row represents, such as one row per month and customer segment.
Use approved table, column, join, and metric definitions where available. Ask the model to list its assumptions and identify the source tables alongside the SQL. If a business term has more than one local meaning, resolve it before deciding whether the query is right. Databricks recommends treating generated SQL as a reviewed draft, not as evidence by itself (Databricks guidance on checking AI-generated SQL).
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Repair Windows errors before they cause bigger problems3Scan for outdated or missing drivers - takes under a minuteInspect the SQL before running it
Read the query against the specification and your organization’s approved schema. A query can be syntactically valid yet answer a different question because it uses the wrong source, relationship, filter, or level of detail.
#1 Best Overall
Verify tables, columns, and joins
- Confirm every referenced table and column exists and is approved for this use.
- Check each join key against a documented relationship; matching column names alone do not prove that two fields should be joined.
- Ask whether either side of a join can contain repeated keys. A one-to-many or many-to-many join can multiply rows and inflate sums or counts.
- Check that the join type preserves the intended population. For example, an inner join can drop records with no matching row, while a left join can retain them.
To detect a bad join, compare row counts and distinct entity keys before and after it. If the count of the intended entity changes unexpectedly, inspect duplicate keys and relationship cardinality before accepting any aggregate.
Check filters, grouping, and calculation stages
- Confirm filters include the intended population and exclusions, and that they are applied at the right stage of the query.
- Check whether the grouping columns produce the specified grain. Extra grouping fields can split totals; missing fields can combine populations that should remain separate.
- Review whether a calculation should happen before or after aggregation, especially for averages, rates, and ratios.
- Check null handling, zero denominators, and whether missing values are excluded, counted, or treated as zero.
Verify dates and calendar boundaries
Confirm which date column is used and whether the organization’s reporting calendar is a standard calendar, fiscal calendar, or another approved schedule. Check boundary conditions: whether the start date is included, whether the end date is included, and how timestamps and time zones are handled. A query grouped by calendar month may not match a fiscal-month report even if both are described as “monthly.”
Validate the result independently
After the logic review, check the output rather than relying on the query’s successful execution. Databricks explicitly distinguishes execution success from correctness (Databricks on trusting AI text-to-SQL for decisions).
- Preview representative records. Inspect a limited sample that includes ordinary cases and likely edge cases. Confirm that the returned rows make sense under the specification.
- Reconcile against a trusted reference. Compare the same population, dates, filters, and metric with an approved query or dashboard. A comparison is meaningful only when both sides use the same definitions and scope.
- Check counts and keys. Examine total rows, distinct entity keys, duplicates, and null rates. Compare them with what the grain and joins imply.
- Test edge cases. Check periods with no records, records with missing values, boundary dates, and entities that might be excluded by a join or filter.
- Explain any difference. If the generated result does not reconcile, identify whether the cause is a definition mismatch, a scope difference, or a query defect. Do not use the number until the discrepancy is understood.
For each proposed query or review method, use the same comparison criteria: approved metric definition, intended population and grain, correct joins and calendar, reconciliation with a trusted reference, appropriately restricted access, and checks that can be repeated after changes.
Limit execution permissions and gate consequential use
Run generated SQL only against approved data with access limited to the task. A review of the text does not replace permission controls: a mistaken query can expose data or change it if the connection is allowed to do so.
Microsoft’s SSMS Copilot documentation is product-specific: it says Copilot runs under the connected user’s security context, does not elevate permissions, and defaults to read-only. DML or DDL execution depends on both the user’s permissions and the configured mode. Those details should not be assumed to apply to other AI SQL tools; check the documentation and settings for the tool you use (Microsoft’s SSMS Copilot transparency note).
Require an accountable person to approve both the SQL and its output when an incorrect number could affect financial reporting, customer communications, or automated decisions. The level of review should match the consequences: a harmless exploratory query is not the same as a number that triggers an action.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Keep a review trail and retest after changes
For results that matter, retain the request or prompt, generated SQL, and output with enough context to explain what was checked. Maintain a set of reviewed test questions with expected results, then rerun them when relevant schema, metric definitions, or models change. This helps catch regressions that a one-time manual review would miss.
GOV.UK’s general guidance on generative AI states that correctness is not guaranteed; it is not SQL-specific, but reinforces why outputs need evaluation rather than automatic acceptance (GOV.UK guidance on generative AI). Microsoft also cautions that generated queries and responses might not be fully accurate or produce the result a user intended (Microsoft’s SSMS Copilot transparency note).
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
