SET NOCOUNT Error in handling SQL call after upgrade

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP












13















We are upgrading our test environment with a new server and updated version of Microsoft SQL Server and have run into an issue.



On the new server, our old code will get "operation is not allowed when the object is closed" when executing some stored procedures. This message never appeared on the old server. When we tracked it down, the issue can be resolved by adding SET NOCOUNT ON; to the stored procedure.



I looked at the defaults on the database and saw no settings that were different (SQL Server 2008 vs SQL Server 2014) related to defaults.



What setting should I be looking at to resolve this globally without needing to add SET NOCOUNT ON to a thousand stored procs?










share|improve this question



















  • 2





    All stored procedures should specify the behavior you rely on, which is much safer than relying on user options. I would even potentially argue that every stored procedure should always start with SET NOCOUNT ON;, always.

    – Aaron Bertrand
    Feb 27 at 22:01












  • @AaronBertrand I agree; the last project I was on had a template that had set nocount on, but that isn’t an option in this project at this time

    – UnhandledExcepSean
    Feb 27 at 22:44











  • Note that you can write a script to alter all stored procedures and append SET NOCOUNT ON; at the start of the stored procedure (after BEGIN). The number of stored procedures shouldn't really be an issue.

    – Erik A
    Feb 28 at 11:37






  • 1





    @Erik-A - you can't be certain a stored procedure starts with BEGIN - it's nice, but not required.

    – Max Vernon
    Feb 28 at 11:48















13















We are upgrading our test environment with a new server and updated version of Microsoft SQL Server and have run into an issue.



On the new server, our old code will get "operation is not allowed when the object is closed" when executing some stored procedures. This message never appeared on the old server. When we tracked it down, the issue can be resolved by adding SET NOCOUNT ON; to the stored procedure.



I looked at the defaults on the database and saw no settings that were different (SQL Server 2008 vs SQL Server 2014) related to defaults.



What setting should I be looking at to resolve this globally without needing to add SET NOCOUNT ON to a thousand stored procs?










share|improve this question



















  • 2





    All stored procedures should specify the behavior you rely on, which is much safer than relying on user options. I would even potentially argue that every stored procedure should always start with SET NOCOUNT ON;, always.

    – Aaron Bertrand
    Feb 27 at 22:01












  • @AaronBertrand I agree; the last project I was on had a template that had set nocount on, but that isn’t an option in this project at this time

    – UnhandledExcepSean
    Feb 27 at 22:44











  • Note that you can write a script to alter all stored procedures and append SET NOCOUNT ON; at the start of the stored procedure (after BEGIN). The number of stored procedures shouldn't really be an issue.

    – Erik A
    Feb 28 at 11:37






  • 1





    @Erik-A - you can't be certain a stored procedure starts with BEGIN - it's nice, but not required.

    – Max Vernon
    Feb 28 at 11:48













13












13








13


2






We are upgrading our test environment with a new server and updated version of Microsoft SQL Server and have run into an issue.



On the new server, our old code will get "operation is not allowed when the object is closed" when executing some stored procedures. This message never appeared on the old server. When we tracked it down, the issue can be resolved by adding SET NOCOUNT ON; to the stored procedure.



I looked at the defaults on the database and saw no settings that were different (SQL Server 2008 vs SQL Server 2014) related to defaults.



What setting should I be looking at to resolve this globally without needing to add SET NOCOUNT ON to a thousand stored procs?










share|improve this question
















We are upgrading our test environment with a new server and updated version of Microsoft SQL Server and have run into an issue.



On the new server, our old code will get "operation is not allowed when the object is closed" when executing some stored procedures. This message never appeared on the old server. When we tracked it down, the issue can be resolved by adding SET NOCOUNT ON; to the stored procedure.



I looked at the defaults on the database and saw no settings that were different (SQL Server 2008 vs SQL Server 2014) related to defaults.



What setting should I be looking at to resolve this globally without needing to add SET NOCOUNT ON to a thousand stored procs?







sql-server sql-server-2008 sql-server-2014 sp-configure






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Feb 27 at 20:51









Max Vernon

51.9k13114230




51.9k13114230










asked Feb 27 at 20:34









UnhandledExcepSeanUnhandledExcepSean

23839




23839







  • 2





    All stored procedures should specify the behavior you rely on, which is much safer than relying on user options. I would even potentially argue that every stored procedure should always start with SET NOCOUNT ON;, always.

    – Aaron Bertrand
    Feb 27 at 22:01












  • @AaronBertrand I agree; the last project I was on had a template that had set nocount on, but that isn’t an option in this project at this time

    – UnhandledExcepSean
    Feb 27 at 22:44











  • Note that you can write a script to alter all stored procedures and append SET NOCOUNT ON; at the start of the stored procedure (after BEGIN). The number of stored procedures shouldn't really be an issue.

    – Erik A
    Feb 28 at 11:37






  • 1





    @Erik-A - you can't be certain a stored procedure starts with BEGIN - it's nice, but not required.

    – Max Vernon
    Feb 28 at 11:48












  • 2





    All stored procedures should specify the behavior you rely on, which is much safer than relying on user options. I would even potentially argue that every stored procedure should always start with SET NOCOUNT ON;, always.

    – Aaron Bertrand
    Feb 27 at 22:01












  • @AaronBertrand I agree; the last project I was on had a template that had set nocount on, but that isn’t an option in this project at this time

    – UnhandledExcepSean
    Feb 27 at 22:44











  • Note that you can write a script to alter all stored procedures and append SET NOCOUNT ON; at the start of the stored procedure (after BEGIN). The number of stored procedures shouldn't really be an issue.

    – Erik A
    Feb 28 at 11:37






  • 1





    @Erik-A - you can't be certain a stored procedure starts with BEGIN - it's nice, but not required.

    – Max Vernon
    Feb 28 at 11:48







2




2





All stored procedures should specify the behavior you rely on, which is much safer than relying on user options. I would even potentially argue that every stored procedure should always start with SET NOCOUNT ON;, always.

– Aaron Bertrand
Feb 27 at 22:01






All stored procedures should specify the behavior you rely on, which is much safer than relying on user options. I would even potentially argue that every stored procedure should always start with SET NOCOUNT ON;, always.

– Aaron Bertrand
Feb 27 at 22:01














@AaronBertrand I agree; the last project I was on had a template that had set nocount on, but that isn’t an option in this project at this time

– UnhandledExcepSean
Feb 27 at 22:44





@AaronBertrand I agree; the last project I was on had a template that had set nocount on, but that isn’t an option in this project at this time

– UnhandledExcepSean
Feb 27 at 22:44













Note that you can write a script to alter all stored procedures and append SET NOCOUNT ON; at the start of the stored procedure (after BEGIN). The number of stored procedures shouldn't really be an issue.

– Erik A
Feb 28 at 11:37





Note that you can write a script to alter all stored procedures and append SET NOCOUNT ON; at the start of the stored procedure (after BEGIN). The number of stored procedures shouldn't really be an issue.

– Erik A
Feb 28 at 11:37




1




1





@Erik-A - you can't be certain a stored procedure starts with BEGIN - it's nice, but not required.

– Max Vernon
Feb 28 at 11:48





@Erik-A - you can't be certain a stored procedure starts with BEGIN - it's nice, but not required.

– Max Vernon
Feb 28 at 11:48










1 Answer
1






active

oldest

votes


















16














SQL Server Configuration has an option called, appropriately, user options, which can be set using the sp_configure system stored procedure. I wrote a blog post on SQL Server Science showing how to inspect and set the user options.



In brief, you can get the "config value" from the old server, using this:



EXEC sys.sp_configure 'user options';


Then, set the new server to use the same options via this:



EXEC sys.sp_configure 'user options', <config value>;
RECONFIGURE


(replace the <config value> with the value from the old server).






share|improve this answer

























  • That almost certainly is the cause (waiting on confirmation now). The old server had a value of 512 which is NOCOUNT according to MS (docs.microsoft.com/en-us/sql/database-engine/configure-windows/…). I didn't see this earlier as I was only looking at @@OPTIONS

    – UnhandledExcepSean
    Feb 27 at 20:49











  • That's definitely correct. If SET NOCOUNT ON solves the issue, setting user options to 512 will fix it.

    – Max Vernon
    Feb 27 at 20:51










Your Answer








StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "182"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);













draft saved

draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f230905%2fset-nocount-error-in-handling-sql-call-after-upgrade%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









16














SQL Server Configuration has an option called, appropriately, user options, which can be set using the sp_configure system stored procedure. I wrote a blog post on SQL Server Science showing how to inspect and set the user options.



In brief, you can get the "config value" from the old server, using this:



EXEC sys.sp_configure 'user options';


Then, set the new server to use the same options via this:



EXEC sys.sp_configure 'user options', <config value>;
RECONFIGURE


(replace the <config value> with the value from the old server).






share|improve this answer

























  • That almost certainly is the cause (waiting on confirmation now). The old server had a value of 512 which is NOCOUNT according to MS (docs.microsoft.com/en-us/sql/database-engine/configure-windows/…). I didn't see this earlier as I was only looking at @@OPTIONS

    – UnhandledExcepSean
    Feb 27 at 20:49











  • That's definitely correct. If SET NOCOUNT ON solves the issue, setting user options to 512 will fix it.

    – Max Vernon
    Feb 27 at 20:51















16














SQL Server Configuration has an option called, appropriately, user options, which can be set using the sp_configure system stored procedure. I wrote a blog post on SQL Server Science showing how to inspect and set the user options.



In brief, you can get the "config value" from the old server, using this:



EXEC sys.sp_configure 'user options';


Then, set the new server to use the same options via this:



EXEC sys.sp_configure 'user options', <config value>;
RECONFIGURE


(replace the <config value> with the value from the old server).






share|improve this answer

























  • That almost certainly is the cause (waiting on confirmation now). The old server had a value of 512 which is NOCOUNT according to MS (docs.microsoft.com/en-us/sql/database-engine/configure-windows/…). I didn't see this earlier as I was only looking at @@OPTIONS

    – UnhandledExcepSean
    Feb 27 at 20:49











  • That's definitely correct. If SET NOCOUNT ON solves the issue, setting user options to 512 will fix it.

    – Max Vernon
    Feb 27 at 20:51













16












16








16







SQL Server Configuration has an option called, appropriately, user options, which can be set using the sp_configure system stored procedure. I wrote a blog post on SQL Server Science showing how to inspect and set the user options.



In brief, you can get the "config value" from the old server, using this:



EXEC sys.sp_configure 'user options';


Then, set the new server to use the same options via this:



EXEC sys.sp_configure 'user options', <config value>;
RECONFIGURE


(replace the <config value> with the value from the old server).






share|improve this answer















SQL Server Configuration has an option called, appropriately, user options, which can be set using the sp_configure system stored procedure. I wrote a blog post on SQL Server Science showing how to inspect and set the user options.



In brief, you can get the "config value" from the old server, using this:



EXEC sys.sp_configure 'user options';


Then, set the new server to use the same options via this:



EXEC sys.sp_configure 'user options', <config value>;
RECONFIGURE


(replace the <config value> with the value from the old server).







share|improve this answer














share|improve this answer



share|improve this answer








edited Mar 1 at 4:04

























answered Feb 27 at 20:42









Max VernonMax Vernon

51.9k13114230




51.9k13114230












  • That almost certainly is the cause (waiting on confirmation now). The old server had a value of 512 which is NOCOUNT according to MS (docs.microsoft.com/en-us/sql/database-engine/configure-windows/…). I didn't see this earlier as I was only looking at @@OPTIONS

    – UnhandledExcepSean
    Feb 27 at 20:49











  • That's definitely correct. If SET NOCOUNT ON solves the issue, setting user options to 512 will fix it.

    – Max Vernon
    Feb 27 at 20:51

















  • That almost certainly is the cause (waiting on confirmation now). The old server had a value of 512 which is NOCOUNT according to MS (docs.microsoft.com/en-us/sql/database-engine/configure-windows/…). I didn't see this earlier as I was only looking at @@OPTIONS

    – UnhandledExcepSean
    Feb 27 at 20:49











  • That's definitely correct. If SET NOCOUNT ON solves the issue, setting user options to 512 will fix it.

    – Max Vernon
    Feb 27 at 20:51
















That almost certainly is the cause (waiting on confirmation now). The old server had a value of 512 which is NOCOUNT according to MS (docs.microsoft.com/en-us/sql/database-engine/configure-windows/…). I didn't see this earlier as I was only looking at @@OPTIONS

– UnhandledExcepSean
Feb 27 at 20:49





That almost certainly is the cause (waiting on confirmation now). The old server had a value of 512 which is NOCOUNT according to MS (docs.microsoft.com/en-us/sql/database-engine/configure-windows/…). I didn't see this earlier as I was only looking at @@OPTIONS

– UnhandledExcepSean
Feb 27 at 20:49













That's definitely correct. If SET NOCOUNT ON solves the issue, setting user options to 512 will fix it.

– Max Vernon
Feb 27 at 20:51





That's definitely correct. If SET NOCOUNT ON solves the issue, setting user options to 512 will fix it.

– Max Vernon
Feb 27 at 20:51

















draft saved

draft discarded
















































Thanks for contributing an answer to Database Administrators Stack Exchange!


  • Please be sure to answer the question. Provide details and share your research!

But avoid


  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f230905%2fset-nocount-error-in-handling-sql-call-after-upgrade%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown






Popular posts from this blog

How to check contact read email or not when send email to Individual?

Bahrain

Postfix configuration issue with fips on centos 7; mailgun relay