SQL Server报告"无效的列名称",但该列存在且查询通过管理工作室工作

Question

我遇到了一些僵局.我有一些由一些C#代码生成的查询.查询在Microsoft SQL Server Management Studio针对同一数据库运行时工作正常.

但是,当我的代码尝试运行相同的查询时,我得到关于无效列的相同错误,并抛出异常.引用此列的所有查询都失败.

最近将该列添加到数据库中.这是一个名为的日期列Incident_Begin_Time_ts.

失败的一个例子是:

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

其他查询Select MAX(Incident_Being_Time_ts);在代码中运行时也会失败,因为它认为列缺失.

有任何想法吗？

Answer 1

只需按Ctrl+ Shift+即可R看到......

在SQL Server Management Studio中,Ctrl + Shift + R刷新Intellisense缓存.这确实阻止了Management Studio抱怨我添加的列无效,但我认为这是一个红色鲱鱼(当我从代码中访问这些新列时,我仍然有问题,就像原始海报一样). (6认同)
似乎每次我添加迁移，然后更新数据库时，我都必须这样做。否则，我得到它是MS SQL Server中的无效列名。作品！非常感谢。 (2认同)
看起来每次创建表或任何类似的东西时，您可能都必须这样做。 (2认同)
当奇怪的事情发生时，上面这通常是我的首选解决方案。然而，在这种情况下，它并没有解决问题。不过，重新启动 SQL Studio 可以解决问题。 (2认同)

Answer 2

我怀疑你有两个同名的表.一个由架构'dbo'(dbo.PerfDiag)拥有,另一个由用于连接到SQL Server的帐户的默认架构(类似userid.PerfDiag)拥有.

如果对模式对象(例如表)具有非限定引用(未通过模式名称限定),则必须解析对象引用.通过按以下顺序搜索具有指定名称的相应类型(表)的对象,可以进行名称解析.该名称解析为第一场比赛:

非限定引用与上述序列中的第一个匹配绑定.

作为一般推荐的做法,出于性能原因,应始终限定对架构对象的引用:

非限定引用可能使存储过程或查询的高速缓存执行计划无效,因为绑定引用的模式可能会根据执行存储过程或查询的凭据而更改.这导致重新编译查询/存储过程,性能损失.重新编译会导致编译锁被取出,阻止其他人访问所需的资源.
名称解析会降低查询执行速度,因为必须进行两次探测以解析对象的可能版本(由'dbo'拥有).这是通常的情况.单个探测器解析名称的唯一时间是当前用户是否拥有指定名称和类型的对象.

[编辑进一步说明]

其他可能性(没有特别的顺序):

仔细检查连接字符串并确保它们显式指定SQL Server实例名称和数据库名称.

+1我使用sql profiler来跟踪这些类型的问题.每当您处理来自其他应用程序的动态SQL时,使用跟踪捕获查询,将其复制并粘贴到新的查询窗口中,单击执行以找出错误.这也将验证您是否正在连接到正确的实例和db,如上所述. (4认同)
首先尝试使用 Ctrl + Shift + R 重新加载缓存。最坏的情况你只会浪费几秒钟。 (4认同)
...稍微偏离主题但是如果您使用分析器来重现性能问题,请记住包括所有设置选项**,特别是ARITHABORT以真正复制查询(以及它的缓存计划) (2认同)

Answer 3

就我而言，我重新启动了 Microsoft SQL Sever Management Studio，这对我来说效果很好。

Answer 4

如果您在事务和SQL语句中运行此操作,则在删除/更改表之前,您也可以获取此消息.

+1。我通过添加新列更改了表，并在引用新列的下一条语句中收到此错误。我通过执行语句来克服这一点，直到一次更改表，然后再执行其余的更改。不是最好的解决方案，但让我畅通无阻。:) (2认同)

Answer 5

我最终关闭并重新启动了 Microsoft SQL Server Management Studio；这为我修复了它。但在其他时候，只需启动一个新的查询窗口就足够了。