This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
SET NOCOUNT ON usage
Why do we use the below statement in Triggers and stored procedures?
SET NOCOUNT ON
Could any one explain me please? I have gone through the similar question posted before. But as I am new learning SQL, I am unable to understand their discussion.
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.
So if you do an UPDATE query (for example) the query will not return the affected rows.
for more information check out => http://msdn.microsoft.com/en-us/library/aa259204(v=sql.80).aspx
Related
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 6 years ago.
Improve this question
I've to help migrating a SQL Server 2008 database to a PostgreSQL 9.4.10 one. The original querys have SET NOCOUNT ON and SET NOCOUNT OFF several times, and I can't change this fact so ignoring the number of rows affected isn't a solution. That's why I need to find an equivalent to this statement, but all I can find are really old posts where they say I should ignore the result. Any ideas? Thanks.
EDIT: these SET NOCOUNTare inside a stored procedure that goes like this:
CREATE PROCEDURE [procedureName]
Declares
--Variables
WITH ENCRYPTION
AS
SET NOCOUNT ON
--Procedure's code
SET NOCOUNT OFF
GO
As I've said this code isn't mine, so I can't post any of it more than the source of my doubt.
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 6 years ago.
Improve this question
I'm trying to create a trigger in the 'CabecDoc' table so that it adds a field to the 'Test' table (the field being 'Artigo').
I thought this trigger would do the trick, but it doesn't! It does nothing! It does not create any record on my 'Test' table. Can you help?
USE [PRICLONEPRJ]
GO
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE TRIGGER [dbo].[CriarContrato]
ON [dbo].[CabecDoc]
AFTER INSERT
AS
BEGIN
-- SET NOCOUNT ON added to prevent extra result sets from
-- interfering with SELECT statements.
set ansi_warnings on
set ansi_nulls on
SET NOCOUNT ON;
INSERT INTO Test (Artigo)
select LinhasDoc.Artigo
from inserted INNER JOIN
LinhasDoc ON inserted.Id = LinhasDoc.IdCabecDoc
END
Is there any way to debug this code within SMSS?
Try insert this row
EXEC xp_logevent 60000, 'CriarContrato works', informational;
at the begining of trigger body. And then you should see this log in SSMS - Object Explorer - Management - Sql Server Logs - Current
If it works, you can add this after INSERT:
declare #log varchar(2048) = CONCAT('CriarContrato inserted ', ##ROWCOUNT, ' rows');
EXEC xp_logevent 60000, #log, informational;
or something else.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Errors: “INSERT EXEC statement cannot be nested.” and “Cannot use the ROLLBACK statement within an INSERT-EXEC statement.” How to solve this?
We have a sproc in production which returns a selection. This selection is populated by an INSERT INTO to a temp table, calling a sproc.
So now we now need to produce another sproc, which will be using the data returned by sproc_1.
The problem is that the new sproc also contains a temp table, which is populated by calling sproc_1.
Obviously we get the SQL error complaining about nested insert-exec.
Any ideas how to get past this?
We have spent a day researching the problem, not finding a working solution.
I doubt you would be able to achieve nested insert exec
References :
http://social.msdn.microsoft.com/forums/en-US/transactsql/thread/e66c9e71-4424-4cf3-920c-6725ffc40162/
But I guess this might help you
http://www.sqlservercentral.com/Forums/Topic13595-8-1.aspx#bm68301
What is the Oracle equivalent of SQL Server's SET NOCOUNT ON?
From the SQL Server documentation:
SET NOCOUNT ON... Stops the message that shows the count of the number of rows affected by a Transact-SQL statement or stored procedure from being returned as part of the result set...
For stored procedures that contain several statements that do not return much actual data, or for procedures that contain Transact-SQL loops, setting SET NOCOUNT to ON can provide a significant performance boost, because network traffic is greatly reduced.
There is no equivalent in Oracle when set nocount on is used inside a stored procedure, simply because it's not necessary to do (inside a procedure or function).
The only vaguely matching thing is set feedback off as mentioned by BigMike
SET FEEDBACK OFF at SQL*plus prompt.
For official docs please refer to this
I am creating a stored procedure in Sql Server 2008 database. I want to return the number of rows affected. Which is a better option SET NOCOUNT OFF or RETURN ##ROWCOUNT?
ALTER PROCEDURE [dbo].[MembersActivateAccount]
#MemberId uniqueidentifier
AS
BEGIN
-- Should I use this?
SET NOCOUNT OFF;
UPDATE [dbo].Members SET accountActive = 1 WHERE id = #MemberId;
--Or should I SET NOCOUNT ON and use the following line instead?
--return ##ROWCOUNT;
END
I know that both work, but which is a better choice and why?
After some trying I am coming to a conclusion that SET NOCOUNT is OFF by default inside stored procedures. Is it possible to change this behavior inside my database?
Use ##RowCount. It's explicit and transparent, it is entirely controlled by your code rather than a built-in behaviour.
The NOCOUNT option can be manually set to default to ON (Optons>Query Execution>SQL Server>Advanced). If you set it this way but then declare SET NOCOUNT OFF in your stored procedure then that local setting takes precedence.
Don't use RETURN for values. By convention RETURN from stored procedures is for error codes, 0 meaning no error and non-0 meaning some kind of problem. If you need data back, the appropriate way to do it is with an OUTPUT parameter. It's a little counter-intuitive based on other languages' use of return.
I know that having SET NOCOUNT ON would make a DataAdapter think there was a concurrency conflict.
You can read about it on MSDN. If the code is going to be used by DataAdapters then obviously don't use SET NOCOUNT ON.
It looks like SqlCommand also has this behaviour, which I guess is the reason why the DataAdapter has a problem (as under the hood it will use a Command object).
Reasons for using SET NOCOUNT ON/OFF:
To control the stack overflow while inserting rows into any table.
Passing the T-Sql messages while executing of the queries or nested queries.
To Show or viewing the latest queries executed.
To get information on the latest record escalation.
Why we use SET NOCOUNT on/off ---
Ans : we can understand this by following steps
step 1 : execute query "Select top 10 * from table name".
step 2 : open message window it shows a message "10 rows affected". it creates extra overheads and extends our execution time.
step 3 : to overcome this extra overheads we use SET NOCOUNT ON. If it is On then it will never count the number of row returns instead it sows a message commands completed successfully.
step 4 : By default NOCOUNT is ON then it counts the number of returned rows that is why my suggestion that it should off during creating new procedures to get better performance from database server.