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

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

它的作用编辑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问题，SET NOCOUNT ON无法设置在哪里

（不，不是this的重复）

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

KB 240882，导致在SQL 2000及更早版本上断开连接的问题