I'm facing a problem now. I use ruby and SQLCMD to generate some TSQL scripts. Now I want to check the syntax of the generated script. I use the following SQL:
SET PARSEONLY ON;
SELECT 888
SET PARSEONLY OFF;
I test it in SSMS, when you select these three statements as a whole batch, sql server will give me the result, which is 888. I don't want the actual result, I just want to test whether the syntax of my script is right. So I tried the following SQL:
SET PARSEONLY ON;
GO
SELECT 888
GO
SET PARSEONLY OFF;
GO
Now if I select all these statements as a whole batch, SQL Server will just tell me Command(s) completed successfully. So what I want to know is whether the SET command should in it's own batch?
Yousui, No what you are doing is almost right; Read here for more info.
Just one thing: you cannot use SET PARSEONLY ON and SET PARSEONLY OFF in the same statement because the query would be executed and not parsed.
So try this:
SET PARSEONLY ON
*-- YOUR QUERY*
GO
SET PARSEONLY OFF
Just remember that PARSEONLY only checks the syntax, not the objects, like tables etc. If you want to do object validation and checks use NOEXEC;
SET NOEXEC ON GO
*-- YOUR QUERY HERE*
SET NOEXEC OFF
Related
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 have many procedures that has set nocount on.
Is it necessary to turn it off at the end of stored procedure?
e.g.:
create procedure DummyProc
as
begin
set nocount on
...
set nocount off
end
set nocount on will disable the X rows affected. message SQL returns. This message is suppressed, in some cases, due to undesired effects with the client executing the stored proc.
set nocount off will undo this suppression. However, set nocount on is a scope setting, and by default, will be turned off when leaving the scope anyway.
Now, is set nocount off necessary? No, as any new commands executed will be in a different scope, and by default set nocount off is always in effect. But as stated above in comments, it's considered a good practice, just to explicitly indicate that this setting will return to normal when the proc is finished executing.
I know this is a rather old post but it was the first hit on Google when I looked for the answer. The response above to test it was a very good idea.
I tested this out and wanted to update the above with some additional details.
The scope you create with a SET NOCOUNT ON flows to any procs which your procedure calls. So if your procedure does SET NOCOUNT ON and then you call a sproc, that sproc gets your SET NOCOUNT setting. The setting DOES go away when you exit your sproc but the setting flows down into called sprocs. If you SET NOCOUNT inside of the CALLED sproc, the outer sproc will have the SET NOCOUNT which it set and the inner sproc won't affect the outer sproc.
So I think you don't really need to reset it at the end of your sproc because your settings will never flow OUT of your sproc upwards; however, if your sproc depends on the setting, it should set it before it needs it because if it gets called from another sproc, it could have a different setting than you assume.
only if you dont want to see
(1 row(s) affected) // or n rows....
most of the time - when you debug
and you use print command - so you want to see pure text of your own... so thats a good practice.
edit
it does Not affect your query result (on or off - it doesn't matter.)- if thats what's your asking. ( thanks JNK).
its simple. you dont need it if another program is running your procedure.
Lets say my python code is calling an mssql procedure, then I don't need the affected row count on my app, so I "SHOULD" definitely put "set nocount on" in my code
I need to surpress messages output from a SQL function. As in 1 row affected. I can't use SET NOCOUNT as it's invalid in a function.
Anyone know a way to do this?
Thanks.
EDIT
I was trying to limit the background information in an attemp to boil the problem down to it's essence. But I'll expand. I'm using MSSQL2005 and NHibernate to insert a record in to a SQL table. On the table I have a computed column that runs the function which is reporting back 1 row affected.
I didn't really want to edit the NHibernate part of the process but it may be unavoidable.
A function that returns "(1 row affected)" will be part of a bigger query in a batch. It makes no sense to have SET NOCOUNT ON in the function
You need to do this:
SET NOCOUNT ON;
SELECT * FROM MyUDFTVF();
Note a stored procedure is simply a wrapper for this
CREATE PROC Whatever
AS
SET NOCOUNT ON;
SELECT * FROM MyUDFTVF();
GO
SET NOCOUNT ON is normally needed to stop triggers etc breaking client code: why do you need it here?
The nocount setting is not available in functions.
Stored procedures allow you to set nocount. So converting the function to a stored procedure would solve the problem.
Otherwise, the calling code will have to set nocount. That shouldn't be hard, but might be tedious if the function is used in many places.
P.S. If you post the reason why suppressing the count messages is required, perhaps we can offer some more solutions.
I want to check the syntax of a SQL query. I thought to do in preparing it, with DbCommand.Prepare method.
Unfortunately, no error or exception.
For example: SELECT * FORM table
Is there a way to check the syntax without executing the query ?
To make it perfect, it has to work on SQL Server, Oracle and IBM DB2
For SQL Server, you can use SET FMTONLY and/or SET NOEXEC
set fmtonly on
go
SELECT * FORM table
go
set fmtonly off
Generally only the database you're using is going to know whether a given query is valid or not. One standard and portable trick is to add a WHERE clause that guarantees nothing will be done, then execute the query; for example execute SELECT * FORM table WHERE 1=0 and see what happens.
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.