Blog / Compiling isn't proof: validate state-changing SQL against the real schema

Compiling isn't proof: validate state-changing SQL against the real schema

'It compiled and the first batch ran fine' is the most expensive false comfort in data work.

Published

June 2026

Length

1 min read

Topics

Patterns · SQL · Testing

"It compiled and the first batch ran fine" is the most expensive false comfort in data work.

C# compiling tells you nothing about the SQL strings inside it. A mistyped column name, a wrong table, a bad cast — all compile clean and fail only when the query actually runs. And "the first batch ran" is often worse than no evidence at all, because the first batch usually exercised the old code path, not the new one you're trying to validate.

The cheap insurance is to run the new state-changing statements against the actual deployed schema, inside a transaction you roll back. The insert, the select, the update all execute — proving the SQL is real against the real columns — and nothing persists. You get the full confidence of a live run with none of the consequences.

Compile-time success tells you the C# is shaped correctly. Only execution against the true schema tells you the query is. Those are two different claims, and only one of them is the one you actually care about.