When AI Gets the Query Wrong and SQL Server Doesn't Complain

SQL Server will tell you when a column doesn't exist. It won't tell you when you've selected the wrong one.

That's an important distinction when you're running T-SQL generated by AI. An invented column name might produce an immediate error, but a perfectly valid column can return perfectly valid data that has absolutely nothing to do with what you're looking for.

You asked the AI assistant for a query, it wrote one referencing a column called Email. The name looked right. The query looked right. And the whole answer arrived with the same confidence you'd expect from someone who knew your database. So you ran it.

Pinal Dave wrote this week about why AI sounds confident when it is wrong -- that the tone of an answer tells you nothing about whether it is true, and that a model with no schema in front of it will invent a column name like Email because that is what tables usually have. He is right. But his post doesn't get into how you catch it in T-SQL, and that is what I want to show here.

An AI-generated query can get a column wrong in two very different ways, and the more dangerous one won't actually produce an error. We'll start with the easy one.

The column does not exist

Here is a CustomerOrders table where there is no Email column in it. The email is actually in another column named ContactEmail, but the AI didn't know that and guessed incorrectly:

SELECT CustomerID, FullName, Email
FROM dbo.CustomerOrders;

Of course, SQL Server stops you cold:

This is the good outcome. The guess was wrong, the column doesn't exist, and SQL Server rejects the query with an error. In this example, nothing was changed. The mistake was immediately obvious and you can correct it easily.

If only every AI-generated query made its mistakes this obvious.

The problem is you only get that error if the invented name happens not to exist. So before you run anything an AI assistant wrote, spend one query confirming what the table actually has:

SELECT c.name AS column_name,
       t.name AS data_type,
       c.max_length,
       c.is_nullable
FROM sys.columns c JOIN sys.types t 
  ON c.user_type_id = t.user_type_id
WHERE c.object_id = OBJECT_ID('dbo.CustomerOrders')
ORDER BY c.column_id;

There is the truth about this table, straight from the catalog. No Email. That column is ContactEmail, and now you know it, because you checked the schema instead of trusting AI's guess. You can also verify the column details in INFORMATION_SCHEMA.COLUMNS, but the catalog views expose more complete metadata. Either way, you're checking the actual table definition rather than relying on AI's assumptions.

If that were the whole problem, you could rely on Msg 207 to protect you and move on. But no. It's not that easy.

The dangerous case: the column exists - but it is the wrong one

Look at that column list again. There are two date columns: OrderDate and ShipDate. Now suppose you asked for a report of when each order shipped, and the AI assistant -- again, without your schema -- reached for the column that sounds like the obvious one:

SELECT CustomerID, FullName, OrderDate AS [When it shipped (per AI)]
FROM dbo.CustomerOrders;

No error. The query ran, returned data, and handed you a ship-date report -- except none of those are ship dates. They are order dates. OrderDate is a real column, so nothing stopped the query. It simply answered the wrong question in the same confident format as the right one. This is the kind of result that ends up in a presentation, an invoice, or an SLA report, and nobody thinks twice about it. Why would they? The query ran, the data looked right, and SQL Server didn't complain. Except the answer was wrong.

Catching this one takes the same habit, carried one step further. The name checked out, so the name is not the test. The values are. Put the two date columns side by side and the gap is immediately visible:

SELECT CustomerID, FullName, OrderDate, ShipDate, 
DATEDIFF(DAY, OrderDate, ShipDate) AS days_order_to_ship
FROM dbo.CustomerOrders;

Every order shipped after it was placed -- nine days later, seven, three. The first report used OrderDate for when it was shipped. ShipDate was not even in the query. Looked reasonable, sure. But it was dead wrong. That is the failure to fear. Not the one that throws an error, but the one that runs clean and gives you bad data -- with the same calm voice that it uses for the correct answers.

The habit that catches both

Pinal's point is that confidence is a writing style, not evidence. On the server, that turns into something you can actually do. Before you trust SQL written by AI, ask the catalog two questions, in this order:

Question	How
Do these columns exist?	Check every name against sys.columns for the target table
Do they mean what the query assumes?	Check the data types and read the values before trusting the result

The first question catches the loud mistakes -- the invented Email that throws Msg 207. The second addresses the quiet ones -- the real OrderDate standing in for ShipDate, which SQL Server has no reason to reject. Both illustrate why successful execution is not proof of a correct answer.

When an AI assistant doesn't have access to your schema, it works from assumptions about what your database probably looks like. And even when it gets the column names right, that doesn't mean it understands what those columns represent.

Checking the schema is a good start, but it isn't enough. You need to verify that the query is returning the data you actually asked for, not simply that it executes without error.

A query that fails is often less dangerous than a query that succeeds.

Just because SQL Server ran it doesn't mean AI got it right.

More to Read

Pinal Dave -- Why AI Sounds Confident When It's Wrong
MSFT -- sys.columns (Transact-SQL)
MSFT -- INFORMATION_SCHEMA.COLUMNS (Transact-SQL)
MSFT -- OBJECT_ID (Transact-SQL)