Is it possible to suppress warnings generated by T-SQL scripts? If so, how?
I know I can turn of the 'records affected' messages with
SET NOCOUNT ON
but is there an equivalent for warnings?
Eg:
Warning: Null value is eliminated by an aggregate or other SET operation.
If I'm expecting these errors, it helps to sift the real errors from the chaff in a big script.
Thanks.
See SET ANSI_WARNINGS {ON | OFF}
Related
Consider the following bit of SQL
SET DATEFORMAT ymd
SET ARITHABORT, ANSI_PADDING, ANSI_WARNINGS, CONCAT_NULL_YIELDS_NULL, QUOTED_IDENTIFIER, ANSI_NULLS, NOCOUNT ON
SET NUMERIC_ROUNDABORT, IMPLICIT_TRANSACTIONS, XACT_ABORT OFF
GO
USE master
GO
IF DB_NAME() <> N'master' SET NOEXEC ON
--
-- Create database [myDatabaseName]
--
PRINT (N'Create database [myDatabaseName]')
GO
CREATE DATABASE myDatabaseName
There is then a very long script setting up tables, views, stored procedures etc etc.
I would like to know if SQL would allow something along the likes of the following pseudo code;
If (myDatabaseName Exists)
Return // in other word abort the script here but don't throw an error
Else
//Carry on and install the database
I am aware of the Exists function in SQL but I can't seem to find anything that would simply abort the remains of the script straightaway.
This script will end up in an installation routine. In theory it should never be in an installer where the database is already present, however I would prefer not to take chances and prepare properly for a potential mistake. It is also crucial that the script does not throw any error as that will just cause the installer to roll back and install nothing.
I'm hoping that something exists in SQL that will just exit a script cleanly if particular conditions are met. By exit I really do mean exit as opposed to simply breaking out of the condition being currently evaluated.
The problem is, your client tool (SSMS, SQLCMd, etc) splits your script into batches based on the location of the GO keyword (it's a client tool thing, not SQL Server at all).
It then sends the first batch. After the first batch is complete (no matter what the outcome), it sends the second batch, then the third after the second, etc.
If you're running with sufficient permissions, a high-valued RAISERROR (severity 20-25) should stop the client tool in its tracks (because it forces the connection closed). It's not that clean though.
Another option is to try to set NOEXEC ON which still does some work with each subsequent batch (compilation) but won't run any of the code1. This allows you a slightly better recovery option if you want some batches at the end to always run, by turning it OFF again.
1Which means you still will see error messages for compilation errors for later batches which rely upon database structures that would have been created in earlier batches, if they weren't being skipped.
You can use GOTO as follows :
If (myDatabaseName Exists)
GOTO QUIT; // in other word abort the script here but don't throw an error
Else
//Carry on and install the database
QUIT:
SELECT 0;
There are several methods for that kind of request :
raiserror('Oh no a fatal error', 20, -1) with log
OR
print 'Fatal error, script will not continue!'
set noexec on
They should work and close the connection.
See here : Answer
I have created EXECUTE SQL TASK in the SSIS package.
I am getting the Error called "INSERT failed because the following SET options have incorrect settings:
"ARITHABORT. Varify the set option are correct for use with indexed
views and/or indexes on computed columns or filtered indexes and query
notification"
But when i am trying execute ditectly in to SQL server management studio.It wont give any error.
Please let me know if you guys has come across this kind of issue.
Thanks
SET ARITHABORT in conjunction with SET ANSI WARNINGS controls how divide by zero and overflow errors are handled.
If you want to ignore the overflow and divide by zero, use this in front of your batch:
SET ARITHABORT OFF
SET ANSI WARNINGS OFF
If your database compatibility level is 80 or earlier, SET ARITHABORT must be on.
Morning folks,
I have this annoying error every time I execute the query on my DTS step. It returns "Invalid Pointer" while the query executes successfully on the Query Analyser.
I tried the :
SET NOCOUNT ON
SET ANSI_WARNINGS OFF
==> No success. Even more with the SET ANSI_WARNINGS OFF I get a new error..
Does anyone have an idea about this problem please ?
Obviously, the problem was from another query and the SET NOCOUNT ON did make it work in the end.
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.