I want to see how many rows are affected for each DDL statement that is run by a query, so I set SET NOCOUNT OFF at the start of each query that is run.
Sample query:
SET NOCOUNT OFF;
GO
BEGIN TRY
BEGIN TRANSACTION
UPDATE dbo.tbProvClause SET ClauseTemplate = 'Clause1' where DocumentName = '\Templates\EndorsAccessPlainLanguageQCEng.CDS';
UPDATE dbo.tbProvClause SET ClauseTemplate = 'Clause 2' where DocumentName = '\Templates\EndorsEnforcedRemovallLtdMktPublicPropertyQCEng.CDS';
UPDATE dbo.tbProvClause SET ClauseTemplateFR = 'Malgré French Clause 1' where DocumentNameFR = '\Templates\EndorsAccessHOPPQcFr.CDS';
UPDATE dbo.tbProvClause SET ClauseTemplateFR = 'Malgré les exceptions Clause 2' where DocumentNameFR = '\Templates\EndorsEnlèvementFTNdomainepublicERLMPublicPropertyQcFr.CDS';
COMMIT TRAN
PRINT 'Script Completed With Success - Changes committed on ' + CAST(current_timestamp AS varchar(25))
END TRY
BEGIN CATCH
--
END CATCH
GO
and it returns
(1 row(s) affected)
(1 row(s) affected)
(1 row(s) affected)
(1 row(s) affected)
Script Completed With Success - Changes committed on Nov 29 2017 12:10PM
This is good. But when I run the same in SQLCMD, I get only 1 row .i.e.
sqlcmd -S testserver -dTestDB -i StackOverflowSQL.sql
(1 rows affected)
Script Completed With Success - Changes committed on Nov 29 2017 12:24PM
How do I retain the ability of the SET NOCOUNT OFF in SQLCMD? The reason I asked this question is that I have a number of scripts that I want to batch using SQLCMD and I will be saving their logs. In this case, the SET NOCOUNT OFF is very useful in checking how many lines of 1 rows affected will give a feedback that the run was successful.
Try something like this and see if it works.
use -v (small letter v).
sqlcmd -v NOCOUNT=OFF -S testserver -dTestDB -i StackOverflowSQL.sql
Or
In the same command prompt first run SET NOCOUNT=OFF before calling sqlcmd .
Look into below documentation link and search for "Variable Precedence". You will get some idea.
https://learn.microsoft.com/en-us/sql/tools/sqlcmd-utility
It's just a hunch. Remove the Go statement after "set nocount off".
First of all "set nocount off" statement does not require a GO. Secondly, I think GO (A batch executor) may be setting the option only for that batch.
There is a rather stupid workaround if my suggestion does not work.
You can:
print ##rowcount
after every sql statement which you may be interested to monitor the row counts.
Found the problem. There were multiple versions of SQLCMD installed in the machine. To find out which version I was using:
E:\Test>where sqlcmd
C:\Program Files\Microsoft SQL Server\100\Tools\Binn\SQLCMD.EXE
C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\110\Tools\Binn\SQLCMD.EXE
The one that I was using was SQL Server 2008 R2 version. the I looked into the system environment variables PATH and changed the order and now it uses the SQL server 2012 version. After changing the PATH
E:\Test>where sqlcmd
C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\110\Tools\Binn\SQLCMD.EXE
C:\Program Files\Microsoft SQL Server\100\Tools\Binn\SQLCMD.EXE
E:\Test>sqlcmd -S testserver -dTestdb -i StackOverflowSQL.sql
(1 rows affected)
(1 rows affected)
(1 rows affected)
(1 rows affected)
Script Completed With Success - Changes committed on Nov 29 2017 3:37PM
It works!
Related
the default textsize in sybase is 32768.
i can see this when i login to sybase and type:
1> select ##textsize
2> go
-----------
32768
(1 row affected)
when i did some googling i got the info that using the set command i can change the default textsize to my own value
1> set textsize 42768
2> go
1> select ##textsize
2> go
-----------
42768
(1 row affected)
But my problem here is this is not persisting.
as soon as i close the session,it sets back to 32768.
does anybody know how could i change the default textsize permanently in sybase.
There is no way to persist this it must be set within each session as required. There is no corresponding parameter for sp_configure.
http://infocenter.sybase.com/help/topic/com.sybase.infocenter.dc31654.1570/html/sag1/X68714.htm
If it's set within a stored procedure, the setting lasts for the stored procedure's scope.
select ##textsize
go
create procedure test_textsize as
set textsize 123456
select ##textsize
go
exec test_textsize
go
select ##textsize
go
Result
session_textsize
----------------
32768
(1 row affected)
proc_textsize
-------------
123456
(1 row affected)
(return status = 0)
session_textsize
----------------
32768
(1 row affected)
Update for Sybase ASE 16
This can be achieved using a login trigger in the login's default database.
create procedure login_trigger as
set textsize 12345
go
Add the login trigger to the user account.
sp_modifylogin a_login, "login script", login_trigger
go
Test in another isql session:
$ isql -U a_login -S SOME_ASE
Password:
1> select ##textsize
2> go
-----------
12345
(1 row affected)
1>
From HERE!
The set textsize command specifies the limit, in bytes, of the text or image data to be returned with a select statement. For example, this command sets the limit on text or image data returned with a select statement to 100 bytes:
set textsize 100
The current setting is stored in the ##textsize global variable. The default setting is controlled by the client program. To reset the default, issue:
set textsize 0
I think the default value is configured when configuring the server.
How can I disable the verbose output that gets printed on the console every time I run large queries in SQL Server 2005 Management Studio...
It keeps saying..
(1 row(s) affected)
(1 row(s) affected)
(1 row(s) affected)
(1 row(s) affected)
and keeps doing that.
I have some print statement in between the SQL, they all get lost! How can I turn this thing off ?
Use this statement on start of batch:
SET NOCOUNT ON;
There is Documentation on MSDN.
You need to write one statement prior your T-SQL.
SET NOCOUNT ON
I have the following stored procedure:
ALTER PROCEDURE [dbo].[spTitle_GetTitleById]
(
#TitleId INT
)
AS
BEGIN
SET NOCOUNT ON;
SELECT
Id,
Name,
Active
FROM
Title
WHERE
Id = #TitleId
END
I was told to use SET NOCOUNT ON; if I don't want messages to be returned. I ran this stored procedure through SQL Server Management Studio 2008 and I got the following message:
(1 row(s) affected)
This is still a message. One of our DBAs said that this will be the case, but when it is run through an application it will not return any messages. Is there a way that I can test to see if messages were returned or not when I use SET NOCOUNT ON; I don't want to assume, I want to know.
I right clicked the stored procedure and selected Execute Stored Procedure... I then set it to OFF, and I got:
(1 row(s) affected)
(1 row(s) affected)
So setting it to ON or OFF it still brought back messages in the Messages tab in the results panel.
Just another question, when will it be wise (in what scenarios) to use SET NOCOUNT OFF;?
SET NOCOUNT ON is reset when the procedure exits and it goes up the call stack. When you execute the procedure from SSMS it generates a script like the following.
DECLARE #return_value int
EXEC #return_value = [dbo].[spTitle_GetTitleById]
#TitleId = 1
SELECT 'Return Value' = #return_value /*Message comes from here*/
If youi wanted to avoid that for some reason you would need to SET NOCOUNT ON in the outer batch. See SET NOCOUNT ON usage for some discussion about the merits of having this ON or OFF
Just another question, when will it be wise (in what scenarios) to use SET NOCOUNT OFF?
See What are the advantages and disadvantages of turning NOCOUNT off in SQL Server queries? For the benefits turning SET NOCOUNT ON
As for why you would want to turn this off (so that rowcounts are returned) - you need this off whenever you want to be able to tell how many rows were affected in situations where there is no resultset, or you wish to be able to get a rowcount without first reading through the entire resultset.
For example in .Net the DataAdapter class uses rowcounts and so setting NOCOUNT ON causes issues when editing or deleting data (source).
That is not correct, script out the proc an make sure it is not OFF instead o ON, if it is ON it should not return (1 row(s) affected) messages
Also how are you executing the proc
is is just this
exec spTitle_GetTitleById 1
I'm working with a lot of TSQL scripts that perform management tasks on the SQL Server. Those scripts are saved as .sql files and executed by a DBA in Microsoft SQL Server Management Studio. I use the print statement to echo some information back to the DBA.
Consider the following simplification of a script:
PRINT 'Update user...'
UPDATE [User] SET UserName = UserName WHERE UserName = 'Administrator'
PRINT 'Delete user...'
DELETE FROM [User] WHERE UserName = 'Nothing'
PRINT 'Update & Delete finished'
When I'm running this script I get the following output:
Update user...
(1 row(s) affected)
Delete user...
(0 row(s) affected)
Update & Delete finished
There is always an enter before the result of the query. Some of my DBA's are complaining about the readability of the output. It is especially hard to interpret the results when a cursor is used in a script.
Is there a way to get rid of the preceding enters when the result of an action is displayed?
You could SET NOCOUNT ON , get the rows affected via ##ROWCOUNT and print a custom message yourself.
I'm adapting a large number of SQL Server 2005 scripts to merge two of our databases together. The scripts are run from a .cmd file which calls sqlcmd to run the scripts in order. However, I'm experiencing one or two issues where the scripts are failing.
I'd like a quick way to get a look at the state of some of the scripts where they go wrong - check variable values, the results of some queries, stuff like that.
If I was having this problem with a .NET assembly, I'd augment the code with Debug.Assert or set breakpoints where I knew failures were going to occur, which would pause program execution and allow me to check out variable values.
I was wondering, is there an equivalent in SQL Server 2005?
I've never managed to make the integrated debugging work well with SQL Server - I usually resort to "printf" debugging, using either PRINT or RAISERROR statements. RAISERROR can do some basic argument formatting, to spit the values out to the messages window. E.g. if you have a parameter #Val1, of type int, you can do:
RAISERROR('Val1 = %i',10,1,#Val1) WITH NOWAIT
(the WITH NOWAIT option causes the message to appear immediately, rather than the usual SQL behaviour of buffering messages/outputs)
This will work:
-- Assert procedure equivalent to other languages.
-- raiserror() will cause sql execution to stop and throw execep in C# code that is running this statement.
-- Usage:
-- declare #shouldBeTrue bit
-- set #shouldBeTrue = case when 1=0 then 1 else 0 end
-- exec _AT3Assert #shouldBeTrue, 'failed'
IF EXISTS (SELECT 1 FROM INFORMATION_SCHEMA.ROUTINES WHERE ROUTINE_NAME = '_AT3Assert' AND ROUTINE_SCHEMA = 'dbo' AND ROUTINE_TYPE = 'PROCEDURE')
EXEC ('DROP PROCEDURE dbo._AT3Assert')
GO
create procedure dbo._AT3Assert
#shouldBeTrue bit,
#errorMsg nvarchar (max)
AS
SET NOCOUNT ON;
if #shouldBeTrue is null or #shouldBeTrue <> 1
begin
raiserror (#errorMsg, -- Message text.
11, -- Severity.
1 -- State.
);
end
GO
I use batch files and check the error code like this:-
SQLCMD.EXE -b -l 30 -E -S <SERVER> -i "<SQLFILE>.sql">>"%LOG_FILE%"2>&1
IF ERRORLEVEL 1 (
ECHO. Failed.
) ELSE (
ECHO. Succeeded.
)