Showing posts with label tsql. Show all posts
Showing posts with label tsql. Show all posts

Monday, March 26, 2012

if condition and batch statements

Is it possible in tsql ? How can I do the following?
if ( 1 = 1)
begin
print 'condition was true'
return --exit the script completely -- how do I do that?
end
-- otherwise continue with the script
print 'continue'
go
print 'with'
go
print 'the'
go
print 'script'
go
Please let me know if this needs further clarification and TIA..sqlster wrote:
> Is it possible in tsql ? How can I do the following?
> if ( 1 = 1)
> begin
> print 'condition was true'
> return --exit the script completely -- how do I do that?
> end
> -- otherwise continue with the script
> print 'continue'
> go
> print 'with'
> go
> print 'the'
> go
> print 'script'
> go
> Please let me know if this needs further clarification and TIA..
Strictly speaking GO isn't a TSQL statement. It's a batch separator
that tells the client to submit a batch of TSQL statements. So the
answer is that it isn't possible in TSQL, it is possible using the
client utilities. Unfortunately you didn't specify what you are using
to execute this script.
On the OSQL command line you can use the -b option to terminate when an
error occurs. Then just put a RAISERROR in your IF statement block.
If you are executing the script as a symin then you can use
RAISERROR with a severity level >= 20 to terminate the connection.
David Portas
SQL Server MVP
--|||No, each batch is separate. If you don't need the GO batch separators:
IF (1=1)
BEGIN
RAISERROR(condition was true',1,1) WITH NOWAIT
RETURN
END
PRINT 'continue'
PRINT 'with'
PRINT 'the'
PRINT 'script'
or
IF (1=1)
BEGIN
PRINT 'Condition was true'
GOTO QuitLabel
END
PRINT 'continue'
PRINT 'with'
PRINT 'the'
PRINT 'script'
QuitLabel:
"sqlster" <nospam@.nospam.com> wrote in message
news:5D6CD06D-134F-4BCF-8A35-C7526405C915@.microsoft.com...
> Is it possible in tsql ? How can I do the following?
> if ( 1 = 1)
> begin
> print 'condition was true'
> return --exit the script completely -- how do I do that?
> end
> -- otherwise continue with the script
> print 'continue'
> go
> print 'with'
> go
> print 'the'
> go
> print 'script'
> go
> Please let me know if this needs further clarification and TIA..|||> RAISERROR(condition was true',1,1) WITH NOWAIT
-- sorry,
RAISERROR('condition was true',1,1) WITH NOWAIT|||David, I am using sql query analyzer.
"David Portas" wrote:

> sqlster wrote:
> Strictly speaking GO isn't a TSQL statement. It's a batch separator
> that tells the client to submit a batch of TSQL statements. So the
> answer is that it isn't possible in TSQL, it is possible using the
> client utilities. Unfortunately you didn't specify what you are using
> to execute this script.
> On the OSQL command line you can use the -b option to terminate when an
> error occurs. Then just put a RAISERROR in your IF statement block.
> If you are executing the script as a symin then you can use
> RAISERROR with a severity level >= 20 to terminate the connection.
> --
> David Portas
> SQL Server MVP
> --
>|||Aaron,
I have whole bunch of create/drop database objects such as views, stored
procs, tables, functions etc. I am not sure what would be impact of removing
all the go statements.
In other words, is there any thing wrong with the following:
IF (1=1)
BEGIN
RAISERROR('condition was true,1,1) WITH NOWAIT
RETURN
END
drop myproc1
create myproc1
...
--go take out go statement
drop myproc1
create myproc1
...
--go take out go statement
drop mytable1
create mytable1
...
TIA...
"Aaron Bertrand [SQL Server MVP]" wrote:

> No, each batch is separate. If you don't need the GO batch separators:
> IF (1=1)
> BEGIN
> RAISERROR(condition was true',1,1) WITH NOWAIT
> RETURN
> END
> PRINT 'continue'
> PRINT 'with'
> PRINT 'the'
> PRINT 'script'
> or
> IF (1=1)
> BEGIN
> PRINT 'Condition was true'
> GOTO QuitLabel
> END
> PRINT 'continue'
> PRINT 'with'
> PRINT 'the'
> PRINT 'script'
> QuitLabel:
>
>
> "sqlster" <nospam@.nospam.com> wrote in message
> news:5D6CD06D-134F-4BCF-8A35-C7526405C915@.microsoft.com...
>
>|||> I have whole bunch of create/drop database objects such as views, stored
> procs, tables, functions etc. I am not sure what would be impact of
> removing
> all the go statements.
Yes, for example, CREATE PROCEDURE must be the first statement in a batch.
Various people deal with this kind of situation in various ways. The way
Management Studio prepares scripts for multiple objects without GO, IIRC, is
that it wraps the CREATE PROCEDURE in dynamic SQL, e.g. EXEC('CREATE
PROCEDURE dbo.whatever ...');
A|||Thank you all for the help...
"Aaron Bertrand [SQL Server MVP]" wrote:

> Yes, for example, CREATE PROCEDURE must be the first statement in a batch.
> Various people deal with this kind of situation in various ways. The way
> Management Studio prepares scripts for multiple objects without GO, IIRC,
is
> that it wraps the CREATE PROCEDURE in dynamic SQL, e.g. EXEC('CREATE
> PROCEDURE dbo.whatever ...');
> A
>
>sql

IF {ELSE IF} Construct

Hi

Since there is no IF {ELSE IF} constructs in TSQL, I assume the following will do the equivalent of ELSE IF, please verify. Thanx :)

IF condition
BEGIN
-- some TSQL
END
ELSE IF condition
BEGIN
-- some TSQL
END
ELSE
BEGIN
-- some TSQL
END

JamesPlease comment on any deviation from standard programming that this IF ELSE IF construct may introduce. I am too novice to see it.

Cheers

James|||This should work, but your code will be more readable if you can use a CASE statement instead.

blindman|||true
but isn't IF and ELSE more efficient than CASE
I assume that because what i said is true in general programming

cheers
james|||For a single criteria IF ELSE is probably more efficient, but when you start nesting IF statements I doubt there is any difference. The db engine has to make the same logical comparisons in either case.

Evaluation of a CASE statement completes as soon as a match is found, and further criteria are not considered. I'm not sure if this is true of nested IF/ELSE statements; ie, the optimizer may evaluate the entire statement. Perhaps someone else on the forum knows how the optimizer handles this scenario.

Truth is, neither of these is a very fast operation when performed against large tables. You gotta do what you gotta do.

blindman|||Originally posted by nano_electronix
Hi

Since there is no IF {ELSE IF} constructs in TSQL, I assume the following will do the equivalent of ELSE IF, please verify. Thanx :)

IF condition
BEGIN
-- some TSQL
END
ELSE IF condition
BEGIN
-- some TSQL
END
ELSE
BEGIN
-- some TSQL
END

James

I think this is the correct solution. Lets say "condition" refers to weekend day, a holiday or a week day flag and "TSQL" refers to three totaly diffrent queries. Your code would be resonable.

Now lets say "TSQL" is identical except for the treatment of a date column and all you want is the words "Holiday", "Weekend" or "Weekday" returned in your query, a CASE statment might be the better choice.

Clear as mud?|||agree :)

Wednesday, March 21, 2012

Identity_insert not happening

I am setting insert_identity to on for a table in t-sql.
The table name is passed as a parameter in the tsql procedure.

When i write the following code.
set @.setStr = 'set IDENTITY_INSERT ' + @.toTableName +' ON'
execute (@.setStr)

and then set the insert query and execute it as follows:

set @.insQuery = 'insert into ' + @.toTableName + ' ( ' + @.colString + ') select ' + @.colString + ' from ' + @.fromTableName
execute(@.insQuery)

when i execute the procedure it doesnt insert values into the table and gives the following error though i am setting the identity to on.

Error: cannot insert explicit value for identity column in table 'emp' when IDENTITY_INSERT is set to OFF.

i cant make out why it is not applying identity_insert to the table.
Can anybody help me out.

Thank YouDon't use EXECUTE as it will run in a different thread/process to the rest of your code - so the code which follows the call, doesn't know anything about the fact you have set IDENTITY_INSERT to ON.

Try using sp_executesql instead. (Books Online has more information on how to use this system stored proc)

macka.|||it doesnt work... :(
beacuse i've to use exec to execute the sp_executesql proc.
so it gives the same result..

so i can try to make one string by putting a newline character between the following 2 strings... and then just run one string... i guess it might be possible..

'set IDENTITY_INSERT ' + @.toTableName +' ON'

and

'insert into ' + @.toTableName + ' ( ' + @.colString + ') select ' + @.colString + ' from ' + @.fromTableName

but the problem is that i dont know how to append a newline character in the string \r \n \\r \\n dont work... can somebody suggest something on this...

Originally posted by macka
Don't use EXECUTE as it will run in a different thread/process to the rest of your code - so the code which follows the call, doesn't know anything about the fact you have set IDENTITY_INSERT to ON.

Try using sp_executesql instead. (Books Online has more information on how to use this system stored proc)

macka.|||Why not just build it as a single string with space between the statements ? I've just tested that and it works fine.

macka.|||Thanks for this.. i really appriciate ur help...
space works and actually newline character is char(10).. it works with this too... :)

Originally posted by macka
Why not just build it as a single string with space between the statements ? I've just tested that and it works fine.

macka.

Friday, March 9, 2012

Identity Increment

If delete all the records from a table that has an incremental identity. Is there a TSQL way of reset the first number on an insert back to be 1 again without going to the table taking it off then saving it the putting it back on again?TRUNCATE table clears all data and resets the Identity counter.|||Perfect! Thank you.

Friday, February 24, 2012

Identity Column

Hi,
How can I disable an integer column from being IDENTITY? I need to do it
with TSQL statements, not SSMS or EM.
Thanks in advance,
LeilaAdd a column to the table, copy the data from the old column (UPDATE), drop the old column, rename
the new column to the old column name. Column order will of course not be preserved.
Or create a new table instead.
You can not disable the identity property for an existing column. The tools does this by creating a
new table (etc.).
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Leila" <Leilas@.hotpop.com> wrote in message news:e2p8moWDHHA.4928@.TK2MSFTNGP02.phx.gbl...
> Hi,
> How can I disable an integer column from being IDENTITY? I need to do it with TSQL statements, not
> SSMS or EM.
> Thanks in advance,
> Leila
>|||Check out SET IDENTITY_INSERT in BOL|||On Tue, 21 Nov 2006 13:55:37 +0100, "Tibor Karaszi"
<tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote:
>You can not disable the identity property for an existing column.
Which is a rather odd limitation. I wonder if there is a reason
behind this, besides "they could not be bothered"?
Roy|||> Which is a rather odd limitation. I wonder if there is a reason
> behind this, besides "they could not be bothered"?
I agree! Perhaps there something at the physical level, possibly combined with transaction logging,
which makes this a non-trivial thing to implement?
OTOH, perhaps there haven't been enough wishes at Connect (used to be sqlwish@.microsoft.com) to
warrant the work?
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Roy Harvey" <roy_harvey@.snet.net> wrote in message
news:4hu5m211073rqv7888n6mlvp5e8elrmbb4@.4ax.com...
> On Tue, 21 Nov 2006 13:55:37 +0100, "Tibor Karaszi"
> <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote:
>>You can not disable the identity property for an existing column.
> Which is a rather odd limitation. I wonder if there is a reason
> behind this, besides "they could not be bothered"?
> Roy|||No, but you can override it with SET IDENTITY_INSERT ON. So, I'm not sure
why someone would want to "disable" it.
Wouldn't a disabled IDENTITY attribute just be an INT (or variant) column?
Doesn't an IDENTITY have other special characteristics?
Anthony Thomas
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:%23qQau9WDHHA.840@.TK2MSFTNGP02.phx.gbl...
> > Which is a rather odd limitation. I wonder if there is a reason
> > behind this, besides "they could not be bothered"?
> I agree! Perhaps there something at the physical level, possibly combined
with transaction logging,
> which makes this a non-trivial thing to implement?
> OTOH, perhaps there haven't been enough wishes at Connect (used to be
sqlwish@.microsoft.com) to
> warrant the work?
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "Roy Harvey" <roy_harvey@.snet.net> wrote in message
> news:4hu5m211073rqv7888n6mlvp5e8elrmbb4@.4ax.com...
> > On Tue, 21 Nov 2006 13:55:37 +0100, "Tibor Karaszi"
> > <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote:
> >
> >>You can not disable the identity property for an existing column.
> >
> > Which is a rather odd limitation. I wonder if there is a reason
> > behind this, besides "they could not be bothered"?
> >
> > Roy
>|||On Tue, 21 Nov 2006 07:45:04 -0600, "Anthony Thomas"
<ALThomas@.kc.rr.com> wrote:
>No, but you can override it with SET IDENTITY_INSERT ON. So, I'm not sure
>why someone would want to "disable" it.
Consider this information from the Books On Line:
The Transact-SQL programming language provides several SET statements
that change the current session handling of specific information.
It then goes on to list SET IDENTITY_INSERT ON as one of these
statements that ONLY APPLY TO THE CURRENT SESSION.
And elsewhere in BOL:
At any time, only one table in a session can have the IDENTITY_INSERT
property set to ON. If a table already has this property set to ON,
and a SET IDENTITY_INSERT ON statement is issued for another table,
Microsoft® SQL Server? returns an error message that states SET
IDENTITY_INSERT is already ON and reports the table it is set ON for.
So disabling the identity property this way doesn't seem very
practical.
>Wouldn't a disabled IDENTITY attribute just be an INT (or variant) column?
>Doesn't an IDENTITY have other special characteristics?
Yes, it would just be whatever numeric type it was defined as.
Roy Harvey
Beacon Falls, CT|||Roy Harvey (roy_harvey@.snet.net) writes:
> Which is a rather odd limitation. I wonder if there is a reason
> behind this, besides "they could not be bothered"?
What is really funny is that in SQL Server Compact/Mobile/Everywhere Edition
you can use ALTER TABLE to add/remove the IDENTITY property from a column.
That makes me suspect that when SQL Server CE originally was developed
they worked from some preliminary spec of features to be added in SQL 7,
which included this piece of DDL, but which was later was cut from the
mainstream product without the CE team being informed.
Of course, since SQL Whatever-it's-called-this-week Edition is an entirely
different architecture from SQL Server, one can not draw any conclusion
how simple/difficult it would be to add DDL to play with IDENTITY in the
mainstream product.
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx

Identity Column

Hi,
How can I disable an integer column from being IDENTITY? I need to do it
with TSQL statements, not SSMS or EM.
Thanks in advance,
Leila
Check out SET IDENTITY_INSERT in BOL
|||On Tue, 21 Nov 2006 13:55:37 +0100, "Tibor Karaszi"
<tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote:

>You can not disable the identity property for an existing column.
Which is a rather odd limitation. I wonder if there is a reason
behind this, besides "they could not be bothered"?
Roy
|||No, but you can override it with SET IDENTITY_INSERT ON. So, I'm not sure
why someone would want to "disable" it.
Wouldn't a disabled IDENTITY attribute just be an INT (or variant) column?
Doesn't an IDENTITY have other special characteristics?
Anthony Thomas

"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:%23qQau9WDHHA.840@.TK2MSFTNGP02.phx.gbl...
> I agree! Perhaps there something at the physical level, possibly combined
with transaction logging,
> which makes this a non-trivial thing to implement?
> OTOH, perhaps there haven't been enough wishes at Connect (used to be
sqlwish@.microsoft.com) to
> warrant the work?
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "Roy Harvey" <roy_harvey@.snet.net> wrote in message
> news:4hu5m211073rqv7888n6mlvp5e8elrmbb4@.4ax.com...
>
|||On Tue, 21 Nov 2006 07:45:04 -0600, "Anthony Thomas"
<ALThomas@.kc.rr.com> wrote:

>No, but you can override it with SET IDENTITY_INSERT ON. So, I'm not sure
>why someone would want to "disable" it.
Consider this information from the Books On Line:
The Transact-SQL programming language provides several SET statements
that change the current session handling of specific information.
It then goes on to list SET IDENTITY_INSERT ON as one of these
statements that ONLY APPLY TO THE CURRENT SESSION.
And elsewhere in BOL:
At any time, only one table in a session can have the IDENTITY_INSERT
property set to ON. If a table already has this property set to ON,
and a SET IDENTITY_INSERT ON statement is issued for another table,
Microsoft SQL Server returns an error message that states SET
IDENTITY_INSERT is already ON and reports the table it is set ON for.
So disabling the identity property this way doesn't seem very
practical.

>Wouldn't a disabled IDENTITY attribute just be an INT (or variant) column?
>Doesn't an IDENTITY have other special characteristics?
Yes, it would just be whatever numeric type it was defined as.
Roy Harvey
Beacon Falls, CT
|||Roy Harvey (roy_harvey@.snet.net) writes:
> Which is a rather odd limitation. I wonder if there is a reason
> behind this, besides "they could not be bothered"?
What is really funny is that in SQL Server Compact/Mobile/Everywhere Edition
you can use ALTER TABLE to add/remove the IDENTITY property from a column.
That makes me suspect that when SQL Server CE originally was developed
they worked from some preliminary spec of features to be added in SQL 7,
which included this piece of DDL, but which was later was cut from the
mainstream product without the CE team being informed.
Of course, since SQL Whatever-it's-called-this-week Edition is an entirely
different architecture from SQL Server, one can not draw any conclusion
how simple/difficult it would be to add DDL to play with IDENTITY in the
mainstream product.
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx

Identity Column

Hi,
How can I disable an integer column from being IDENTITY? I need to do it
with TSQL statements, not SSMS or EM.
Thanks in advance,
LeilaAdd a column to the table, copy the data from the old column (UPDATE), drop
the old column, rename
the new column to the old column name. Column order will of course not be pr
eserved.
Or create a new table instead.
You can not disable the identity property for an existing column. The tools
does this by creating a
new table (etc.).
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Leila" <Leilas@.hotpop.com> wrote in message news:e2p8moWDHHA.4928@.TK2MSFTNGP02.phx.gbl...[v
bcol=seagreen]
> Hi,
> How can I disable an integer column from being IDENTITY? I need to do it w
ith TSQL statements, not
> SSMS or EM.
> Thanks in advance,
> Leila
>[/vbcol]|||Check out SET IDENTITY_INSERT in BOL|||On Tue, 21 Nov 2006 13:55:37 +0100, "Tibor Karaszi"
<tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote:

>You can not disable the identity property for an existing column.
Which is a rather odd limitation. I wonder if there is a reason
behind this, besides "they could not be bothered"?
Roy|||> Which is a rather odd limitation. I wonder if there is a reason
> behind this, besides "they could not be bothered"?
I agree! Perhaps there something at the physical level, possibly combined wi
th transaction logging,
which makes this a non-trivial thing to implement?
OTOH, perhaps there haven't been enough wishes at Connect (used to be sqlwis
h@.microsoft.com) to
warrant the work?
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Roy Harvey" <roy_harvey@.snet.net> wrote in message
news:4hu5m211073rqv7888n6mlvp5e8elrmbb4@.
4ax.com...
> On Tue, 21 Nov 2006 13:55:37 +0100, "Tibor Karaszi"
> <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote:
>
> Which is a rather odd limitation. I wonder if there is a reason
> behind this, besides "they could not be bothered"?
> Roy|||No, but you can override it with SET IDENTITY_INSERT ON. So, I'm not sure
why someone would want to "disable" it.
Wouldn't a disabled IDENTITY attribute just be an INT (or variant) column?
Doesn't an IDENTITY have other special characteristics?
Anthony Thomas
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:%23qQau9WDHHA.840@.TK2MSFTNGP02.phx.gbl...
> I agree! Perhaps there something at the physical level, possibly combined
with transaction logging,
> which makes this a non-trivial thing to implement?
> OTOH, perhaps there haven't been enough wishes at Connect (used to be
sqlwish@.microsoft.com) to
> warrant the work?
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "Roy Harvey" <roy_harvey@.snet.net> wrote in message
> news:4hu5m211073rqv7888n6mlvp5e8elrmbb4@.
4ax.com...
>|||On Tue, 21 Nov 2006 07:45:04 -0600, "Anthony Thomas"
<ALThomas@.kc.rr.com> wrote:

>No, but you can override it with SET IDENTITY_INSERT ON. So, I'm not sure
>why someone would want to "disable" it.
Consider this information from the Books On Line:
The Transact-SQL programming language provides several SET statements
that change the current session handling of specific information.
It then goes on to list SET IDENTITY_INSERT ON as one of these
statements that ONLY APPLY TO THE CURRENT SESSION.
And elsewhere in BOL:
At any time, only one table in a session can have the IDENTITY_INSERT
property set to ON. If a table already has this property set to ON,
and a SET IDENTITY_INSERT ON statement is issued for another table,
Microsoft SQL Server returns an error message that states SET
IDENTITY_INSERT is already ON and reports the table it is set ON for.
So disabling the identity property this way doesn't seem very
practical.

>Wouldn't a disabled IDENTITY attribute just be an INT (or variant) column?
>Doesn't an IDENTITY have other special characteristics?
Yes, it would just be whatever numeric type it was defined as.
Roy Harvey
Beacon Falls, CT|||Roy Harvey (roy_harvey@.snet.net) writes:
> Which is a rather odd limitation. I wonder if there is a reason
> behind this, besides "they could not be bothered"?
What is really funny is that in SQL Server Compact/Mobile/Everywhere Edition
you can use ALTER TABLE to add/remove the IDENTITY property from a column.
That makes me suspect that when SQL Server CE originally was developed
they worked from some preliminary spec of features to be added in SQL 7,
which included this piece of DDL, but which was later was cut from the
mainstream product without the CE team being informed.
Of course, since SQL Whatever-it's-called-this-week Edition is an entirely
different architecture from SQL Server, one can not draw any conclusion
how simple/difficult it would be to add DDL to play with IDENTITY in the
mainstream product.
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx