受到这个问题的启发,在SET NOCOUNT上有不同的观点…
我们应该使用SET NOCOUNT ON SQL Server吗?如果不是,为什么不是?
它的作用编辑6,2011年7月22日
它在任何DML之后抑制“受影响的xx行”消息。这是一个结果集,当发送时,客户端必须处理它。它很小,但可测量(见下面的答案)
对于触发器等,客户端将收到多个“受影响的xx行”,这将导致一些orm, MS Access, JPA等的各种错误(见下面的编辑)
背景:
一般接受的最佳实践(我认为直到这个问题)是在SQL Server的触发器和存储过程中使用SET NOCOUNT ON
。我们到处使用它,快速谷歌显示大量的SQL Server mvp也同意。
MSDN说这会破坏net SQLDataAdapter。
现在,这对我来说意味着SQLDataAdapter仅限于完全简单的CRUD处理,因为它期望匹配“受影响的n行”消息。所以,我不能用:
在这个问题中marc_s(谁知道他的SQL东西)说不要使用它。这与我的想法不同(我认为自己在SQL方面也有一定的能力)。
我可能遗漏了一些东西(尽管指出显而易见的事实),但你们怎么看?
注意:我已经好几年没有看到这个错误了,因为我现在不使用SQLDataAdapter。
评论和问题后的编辑:
编辑:更多想法…
我们有多个客户端:一个可能使用c# SQLDataAdaptor,另一个可能使用来自Java的nHibernate。SET NOCOUNT ON
可以以不同的方式影响这些。
如果您将存储的proc视为方法,那么假定某些内部处理以某种方式为您自己的目的是不合适的(反模式)。
编辑2:a 触发中断nHibernate问题,其中SET NOCOUNT ON
不能设置
(不,它不是这的副本)
编辑3:更多信息,感谢我的MVP同事
编辑4:2011年5月13日
编辑5:14 2011年6月
打破JPA,存储过程与表变量:JPA 2.0是否支持SQL Server表变量?
编辑6:15 2011年8月
SSMS“Edit rows”数据网格需要SET NOCOUNT ON: 用GROUP BY更新触发器
编辑07 2013年3月
更深入的细节来自@RemusRusanu:
SET NOCOUNT ON真的有那么大的性能差异吗