SET NOCOUNT ON usage

Question

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?

Answer 1

SET NOCOUNT ON even does allows to access to the affected rows like this:

SET NOCOUNT ON

DECLARE @test TABLE (ID int)

INSERT INTO @test
VALUES (1),(2),(3)

DECLARE @affectedRows int = -99  

DELETE top (1)
  FROM @test
SET @affectedRows = @@rowcount

SELECT @affectedRows as affectedRows

Results

affectedRows

1

Messages

Commands completed successfully.

Completion time: 2020-06-18T16:20:16.9686874+02:00

Answer 2

If you're saying you might have different clients as well, there are problems with classic ADO if SET NOCOUNT is not set ON.

One I experience regularly: if a stored procedure executes a number of statements (and thus a number of "xxx rows affected" messages are returned), ADO seems not to handle this and throws the error "Cannot change the ActiveConnection property of a Recordset object which has a Command object as its source."

So I generally advocate setting it ON unless there's a really really good reason not to. you may have found the really really good reason which I need to go and read into more.

Answer 3

One place that SET NOCOUNT ON can really help is where you are doing queries in a loop or a cursor. This can add up to a lot of network traffic.

CREATE PROCEDURE NoCountOn
AS
set nocount on
    DECLARE @num INT = 10000
    while @num > 0
    begin
       update MyTable SET SomeColumn=SomeColumn
       set @num = @num - 1
    end
GO


CREATE PROCEDURE NoCountOff
AS
set nocount off
    DECLARE @num INT = 10000
    while @num > 0
    begin
       update MyTable SET SomeColumn=SomeColumn
       set @num = @num - 1
    end
GO

Turning on client statistics in SSMS, a run of EXEC NoCountOn and EXEC NoCountOff shows that there was an extra 390KB traffic on the NoCountOff one:

Probably not ideal to be doing queries in a loop or cursor, but we don't live in in ideal world either :)

Answer 4

I know it's pretty old question. but just for update.

Best way to use "SET NOCOUNT ON" is to put it up as a first statement in your SP and setting it OFF again just before the last SELECT statement.

Answer 5

I don't know how to test SET NOCOUNT ON between client and SQL, so I tested a similar behavior for other SET command "SET TRANSACTION ISOLATION LEVEL READ UNCIMMITTED"

I sent a command from my connection changing the default behavior of SQL (READ COMMITTED), and it was changed for the next commands. When I changed the ISOLATION level inside a stored procedure, it didn't change the connection behavior for the next command.

Current conclusion,

1. Changing settings inside stored procedure doesn't change the connection default settings.
2. Changing setting by sending commands using the ADOCOnnection changes the default behavior.

I think this is relevant to other SET command such like "SET NOCOUNT ON"

Answer 6

• When SET NOCOUNT is ON, the count (indicating the number of rows affected by a Transact-SQL statement) is not returned. When SET NOCOUNT is OFF, the count is returned. It is used with any SELECT, INSERT, UPDATE, DELETE statement.

• The setting of SET NOCOUNT is set at execute or run time and not at parse time.

• SET NOCOUNT ON improves stored procedure (SP) performance.

• Syntax: SET NOCOUNT { ON | OFF }

Example of SET NOCOUNT ON:

Example of SET NOCOUNT OFF: