SQL Server reports 'Invalid column name', but the column is present and the query works through management studio

I've hit a bit of an impasse. I have a query that is generated by some C# code. The query works fine in Microsoft SQL Server Management Studio when run against the same database.

However when my code tries to run the same query I get the same error about an invalid column and an exception is thrown. All queries that reference this column are failing.

The column in question was recently added to the database. It is a date column called Incident_Begin_Time_ts .

An example that fails is:

select * from PerfDiag 
where Incident_Begin_Time_ts > '2010-01-01 00:00:00';

Other queries like Select MAX(Incident_Being_Time_ts); also fail when run in code because it thinks the column is missing.

Any ideas?

Solution 1:

Just press Ctrl + Shift + R and see...

In SQL Server Management Studio, Ctrl+Shift+R refreshes the local cache.

Solution 2:

I suspect that you have two tables with the same name. One is owned by the schema 'dbo' (dbo.PerfDiag), and the other is owned by the default schema of the account used to connect to SQL Server (something like userid.PerfDiag).

When you have an unqualified reference to a schema object (such as a table) — one not qualified by schema name — the object reference must be resolved. Name resolution occurs by searching in the following sequence for an object of the appropriate type (table) with the specified name. The name resolves to the first match:

• Under the default schema of the user.
• Under the schema 'dbo'.

The unqualified reference is bound to the first match in the above sequence.

As a general recommended practice, one should always qualify references to schema objects, for performance reasons:

• An unqualified reference may invalidate a cached execution plan for the stored procedure or query, since the schema to which the reference was bound may change depending on the credentials executing the stored procedure or query. This results in recompilation of the query/stored procedure, a performance hit. Recompilations cause compile locks to be taken out, blocking others from accessing the needed resource(s).

• Name resolution slows down query execution as two probes must be made to resolve to the likely version of the object (that owned by 'dbo'). This is the usual case. The only time a single probe will resolve the name is if the current user owns an object of the specified name and type.

[Edited to further note]

The other possibilities are (in no particular order):

• You aren't connected to the database you think you are.
• You aren't connected to the SQL Server instance you think you are.

Double check your connect strings and ensure that they explicitly specify the SQL Server instance name and the database name.

Solution 3:

In my case I restart Microsoft SQL Sever Management Studio and this works well for me.

Solution 4:

If you are running this inside a transaction and a SQL statement before this drops/alters the table you can also get this message.