受这个问题的启发，在SET NOCOUNT上有不同的看法…

我们是否应该对SQL Server使用SET NOCOUNT ON？如果没有，为什么不呢？

它的作用 编辑6，2011年7月22日

它抑制了任何DML之后的“受影响的xx行”消息。这是一个结果集，发送时，客户端必须对其进行处理。它很小，但是可以测量（请参见下面的答案）

对于触发器等，客户端将收到多个“受影响的xx行”，这将导致某些ORM，MS Access，JPA等的各种错误（请参见下面的编辑）

背景：

公认的最佳实践（直到这个问题之前，我一直认为）是SET NOCOUNT ON在SQL
Server的触发器和存储过程中使用。我们到处都使用它，一个快速的Google也显示了很多SQL Server MVP的共识。

MSDN表示，这可能会破坏.net SQLDataAdapter。

现在，这对我来说意味着SQLDataAdapter仅限于完全CRUD处理，因为它希望“ n个受影响的行”消息能够匹配。因此，我不能使用：

• 如果存在，避免重复（不影响任何行的消息） 注意：请谨慎使用
• 不存在（行数少于预期）
• 过滤掉琐碎的更新（例如，实际上没有数据更改）
• 之前进行任何表访问（例如记录）
• 隐藏复杂性或去甲化作用
• 等等

在问题marc_s（谁知道他的SQL知识）说不要使用它。这与我的想法有所不同（我也认为自己在SQL方面有些能力）。

我有可能遗漏了一些东西（请指出明显的地方），但是您在那里的人们对此有何看法？

注意：已经有好几年了，因为我现在不使用SQLDataAdapter，所以看到了此错误。

在评论和问题之后进行编辑：

编辑：更多的想法…

我们有多个客户端：一个可以使用C＃SQLDataAdaptor，另一个可以使用Java的nHibernate。这些可能会以不同的方式受到影响SET NOCOUNT ON。

如果将存储的procs当作方法，那么假设某些内部处理以某种方式用于您自己的目的是不好的形式（反模式）。

编辑2：触发打破nHibernate问题，SETNOCOUNT ON无法设置在哪里

编辑3：还有更多信息，多亏了我的MVP同事

• KB 240882，导致在SQL 2000及更早版本上断开连接的问题
• 性能提升演示