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.
Related
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!
I'm running SQL Server 2012.
I have a create procedure statement:
USE [dbname]
GO
IF EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].[Test]') AND type in (N'P', N'PC'))
DROP PROCEDURE [dbo].[Test]
GO
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE PROCEDURE [dbo].[Test]
AS
SELECT 1
When I run this with dbname equals one database, I get:
(1 row(s) affected)
When running it dbname equals another database on the same server, I get:
Command(s) completed successfully.
Obviously this is a database setting or something specific to the database, but I can't seem to find anything. Does anyone know what is causing the difference?
Thanks in advance.
This may be cause of DDL trigger existence. as you mentioned in your comments, one of the triggers has SET NO COUNT ON, which will be 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. if you comment it, or add it to the other trigger too, you will see the same results for both above mentioned scenarios.
The following query returns two different results on two instances of SQL Server 2008 R2:
create table a(id int)
insert into a(id)
values(1)
insert into a(id)
values(2)
select
id,
(select count(dbo.a.id) from dbo.a where dbo.a.id = "a"."id")
from a
where a.id = 1
First machine gives
id
----------- -----------
1 2
Second machine gives
id
----------- -----------
1 1
We know how to fix this problem by using an explicit alias in the subquery. But because we use constructions like this a lot, it would be an immense work to do. So we would like to understand the problem.
Is there maybe an option in SQL Server to control this behaviour?
2013/07/22:
DBCC USEROPTIONS;SELECT ##VERSION; gives
Set Option Value
----------------------------- ----------------
textsize 2147483647
language Deutsch
dateformat dmy
datefirst 1
lock_timeout -1
quoted_identifier SET
arithabort SET
ansi_null_dflt_on SET
ansi_warnings SET
ansi_padding SET
ansi_nulls SET
concat_null_yields_null SET
isolation level read committed
------------------------------------
Microsoft SQL Server 2008 R2 (SP1) - 10.50.2500.0 (Intel X86)
Jun 17 2011 00:57:23
Copyright (c) Microsoft Corporation
Enterprise Edition on Windows NT 6.0 <X86> (Build 6002: Service Pack 2)
and
Set Option Value
----------------------------- ----------------
textsize 2147483647
language Deutsch
dateformat dmy
datefirst 1
lock_timeout -1
quoted_identifier SET
arithabort SET
ansi_null_dflt_on SET
ansi_warnings SET
ansi_padding SET
ansi_nulls SET
concat_null_yields_null SET
isolation level read committed
------------------------------------
Microsoft SQL Server 2008 R2 (RTM) - 10.50.1600.1 (X64)
Apr 2 2010 15:48:46
Copyright (c) Microsoft Corporation
Standard Edition (64-bit) on Windows NT 5.2 <X64> (Build 3790: Service Pack 2)
For the first server the query work how we want it.
2013/07/24
It seems not to depend on the server but on the databases.
Server:
Set Option Value
---------------------------- ----------------------------------------------
textsize 2147483647
language Deutsch
dateformat dmy
datefirst 1
lock_timeout -1
quoted_identifier SET
arithabort SET
ansi_null_dflt_on SET
ansi_warnings SET
ansi_padding SET
ansi_nulls SET
concat_null_yields_null SET
isolation level read committed
(13 Zeile(n) betroffen)
Die DBCC-Ausführung wurde abgeschlossen. Falls DBCC Fehlermeldungen ausgegeben hat, wenden Sie sich an den Systemadministrator.
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Microsoft SQL Server 2008 R2 (SP1) - 10.50.2500.0 (Intel X86)
Jun 17 2011 00:57:23
Copyright (c) Microsoft Corporation
Enterprise Edition on Windows NT 6.0 <X86> (Build 6002: Service Pack 2)
(1 Zeile(n) betroffen)
Following query:
create table a(id int)
insert into a(id)
values(1)
insert into a(id)
values(2)
select * from a
select
id,
(select count(dbo.a.id) from dbo.a where dbo.a.id = "a"."id")
from a
where a.id = 1
drop table a
SELECT USER_NAME() AS CurrentUser;
SELECT SCHEMA_NAME() AS CurrentSchema;
First database gives:
id
-----------
1
2
(2 Zeile(n) betroffen)
id
----------- -----------
1 2
(1 Zeile(n) betroffen)
CurrentUser
--------------------------
dbo
(1 Zeile(n) betroffen)
CurrentSchema
--------------------------
dbo
(1 Zeile(n) betroffen)
Second database gives:
id
-----------
1
2
(2 Zeile(n) betroffen)
id
----------- -----------
1 1
(1 Zeile(n) betroffen)
CurrentUser
-----------------------
dbo
(1 Zeile(n) betroffen)
CurrentSchema
-----------------------
dbo
(1 Zeile(n) betroffen)
The simplest explanation could be that those a tables have diff. rows.
Otherwise, I can't reproduce the problem. A query that references objects without a explicit schema (ex. SELECT * FROM A) can give you diff. results on the same server if
1) That query is executed by diff. users.
2) The users are mapped to diff. schemas (ex. dbo and dbo2).
3) There are two(or more) tables/objects with the same name in diff. schemas (ex: dbo.A and dbo2.A).
Run this script in SSMS with SQLCMD mode selected (menu: Query > SQLCMD mode):
SET NOCOUNT ON;
CREATE DATABASE Test;
GO
USE Test;
GO
CREATE TABLE dbo.A(ID INT);
INSERT INTO dbo.A(ID) VALUES (1);
GO
CREATE SCHEMA dbo2;
GO
CREATE TABLE dbo2.A(ID INT);
INSERT INTO dbo2.A(ID) VALUES (1),(2);
GO
-- Test database has two tables [A] with diff. schema (dbo, dbo2)
USE master;
GO
CREATE LOGIN login_test_1 WITH PASSWORD='pas$w0Rd', DEFAULT_DATABASE=Test;
GO
CREATE LOGIN login_test_2 WITH PASSWORD='pas$w0Rd', DEFAULT_DATABASE=Test;
GO
USE Test;
GO
-- This user is mapped to schema [dbo]
CREATE USER user_test_1 FOR LOGIN login_test_1 WITH DEFAULT_SCHEMA=dbo;
GO
GRANT SELECT ON dbo.A TO user_test_1;
GO
GRANT SELECT ON dbo2.A TO user_test_1;
GO
-- This user is mapped to schema [dbo2] (!)
CREATE USER user_test_2 FOR LOGIN login_test_2 WITH DEFAULT_SCHEMA=dbo2;
GO
GRANT SELECT ON dbo.A TO user_test_2;
GO
GRANT SELECT ON dbo2.A TO user_test_2;
GO
-- Test login_test_1
:CONNECT (local)\SQL2008R2 -U login_test_1 -P pas$w0Rd
SELECT USER_NAME() AS CurrentUser;
SELECT SCHEMA_NAME() AS CurrentSchema;
SELECT *
FROM A;
GO
-- Test login_test_2
:CONNECT (local)\SQL2008R2 -U login_test_2 -P pas$w0Rd
SELECT USER_NAME() AS CurrentUser;
SELECT SCHEMA_NAME() AS CurrentSchema;
SELECT *
FROM A;
GO
SET NOCOUNT OFF;
Results:
Connecting to (local)\SQL2008R2 as login_test_1...
CurrentUser
--------------------------------------------------------------------------------------------------------------------------------
user_test_1
CurrentSchema
--------------------------------------------------------------------------------------------------------------------------------
dbo
ID
-----------
1
Disconnecting connection from (local)\SQL2008R2 as login_test_1...
Connecting to (local)\SQL2008R2 as login_test_2...
CurrentUser
--------------------------------------------------------------------------------------------------------------------------------
user_test_2
CurrentSchema
--------------------------------------------------------------------------------------------------------------------------------
dbo2
ID
-----------
1
2
Disconnecting connection from (local)\SQL2008R2 as login_test_2...
In this case, login_test_1 (dbo) gets 1 row but login_test_2 (dbo2) gets 2 rows.
Cleanup script:
/*
DROP DATABASE Test;
DROP LOGIN login_test_1;
DROP LOGIN login_test_2;
GO
*/
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.