Inspired by this question where there are differing views on SET NOCOUNT…

Should we use SET NOCOUNT ON for SQL Server? If not, why not?

What it does Edit 6, on 22 Jul 2011

It suppresses the “xx rows affected” message after any DML. This is a resultset and when sent, the client must process it. It’s tiny, but measurable (see answers below)

For triggers etc, the client will receive multiple “xx rows affected” and this causes all manner of errors for some ORMs, MS Access, JPA etc (see edits below)


General accepted best practice (I thought until this question) is to use SET NOCOUNT ON in triggers and stored procedures in SQL Server. We use it everywhere and a quick google shows plenty of SQL Server MVPs agreeing too.

MSDN says this can break a .net SQLDataAdapter.

Now, this means to me that the SQLDataAdapter is limited to utterly simply CRUD processing because it expects the “n rows affected” message to match. So, I can’t use:

  • IF EXISTS to avoid duplicates (no rows affected message) Note: use with caution
  • WHERE NOT EXISTS (less rows then expected
  • Filter out trivial updates (eg no data actually changes)
  • Do any table access before (such as logging)
  • Hide complexity or denormlisation
  • etc

In the question marc_s (who knows his SQL stuff) says do not use it. This differs to what I think (and I regard myself as somewhat competent at SQL too).

It’s possible I’m missing something (feel free to point out the obvious), but what do you folks out there think?

Note: it’s been years since I saw this error because I don’t use SQLDataAdapter nowadays.

Edits after comments and questions:

Edit: More thoughts…

We have multiple clients: one may use a C# SQLDataAdaptor, another may use nHibernate from Java. These can be affected in different ways with SET NOCOUNT ON.

If you regard stored procs as methods, then it’s bad form (anti-pattern) to assume some internal processing works a certain way for your own purposes.

Edit 2: a trigger breaking nHibernate question, where SET NOCOUNT ON can not be set

(and no, it’s not a duplicate of this)

Edit 3: Yet more info, thanks to my MVP colleague

Edit 4: 13 May 2011

Breaks Linq 2 SQL too when not specified?

Edit 5: 14 Jun 2011

Breaks JPA, stored proc with table variables: Does JPA 2.0 support SQL Server table variables?

Edit 6: 15 Aug 2011

The SSMS “Edit rows” data grid requires SET NOCOUNT ON: Update trigger with GROUP BY

Edit 7: 07 Mar 2013

More in depth details from @RemusRusanu:
Does SET NOCOUNT ON really make that much of a performance difference

Ok now I’ve done my research, here is the deal:

  • In TDS protocol SET NOCOUNT ON only saves 9-bytes per query, which doesn’t seem that much. I used to think that 9 row(s) affected was returned from server in plain text but it doesn’t seem to be the case. It’s in fact a small message packet called DONE_IN_PROC.

  • Microsoft actually encourages the use of SET NOCOUNT ON in Stored Procedures, as per the book “Improving .NET Application Performance and Scalability” (page 541). I would not base my design decisions upon SqlDataAdapter.

So I think you can stick with SET NOCOUNT ON‘s if the cost is less than switching to another technology. I would still consider abandoning SqlDataAdapter since you still don’t know what kind of design quirk you’ll encounter next.

EDIT: @racingsnail pointed out that the network roundtrip delay is a bigger performance killer than the packet size. He has a point but a second network packet wouldn’t cause the same delay as the roundtrip latency because the packets would be sent in tandem and would not require acknowledgement. So it may cause far less delay than the actual network roundtrip latency.

EDIT 2: Here is a very detailed analysis about insignificant overhead of SET NOCOUNT setting:

Original address:

if you want to reproduce, please indicate the source:
SET NOCOUNT ON usage - CodeDay