Performance Effects of NOCOUNT

  • The big thing to take into account with NOCOUNT (or read uncommitted isolation level) is the fairly recently (last 18 months or so I believe) discovered situation whereby you can double read or miss data. Note that this is not the same as the effects that can come from uncommitted transactions.

    Best,
    Kevin G. Boles
    SQL Server Consultant
    SQL MVP 2007-2012
    TheSQLGuru on googles mail service

  • I've always wondered why SET NOCOUNT ON has not been the default. It seems self-evident that doing more work takes longer, and should be made optional. Basically, don't do the work if you aren't going to use it.

    And I'd prefer SET COUNT OFF as at least an optional syntax.

  • I couldn't agree with you more. I have always wondered why the double negative. Didn't we all learn that in programming 101. And WHY is it the default behavior. Thanks for bringing that up.

  • Cliff Jones (12/7/2007)


    I couldn't agree with you more. I have always wondered why the double negative. Didn't we all learn that in programming 101. And WHY is it the default behavior. Thanks for bringing that up.

    My best guess is that it harkens back vestigially to very early days, when interactive SQL was a primary interface to the database; and it gave you some feedback on whether or not the expected action had taken place. And we're still stuck with it. No one has had the courage to deprecate it, at least as a default behavior.

  • I'm surprised that no one has mentioned that the two procedures listed in the article are exactly the same. Also, the article goes on to mention procedures, such as "AddTestWithoutNoCount" that are not listed.

  • AddTestWithoutNoCount is shown on the bottom right of the 4 stored procedures but as you point out it is identical to AddTestWithdbo.

Viewing 6 posts - 31 through 35 (of 35 total)

You must be logged in to reply to this topic. Login to reply