Beginning Microsoft SQL Server 2008 ... - S3 Tech Training
Share Embed Flag
Download ePaper

Beginning Microsoft SQL Server 2008 ... - S3 Tech Training

Beginning Microsoft SQL Server 2008 ... - S3 Tech Training Beginning Microsoft SQL Server 2008 ... - S3 Tech Training

cdn.s3techtraining.com
from cdn.s3techtraining.com More from this publisher
17.06.2013 Views

Chapter 11: Writing Scripts and Batches Setting Variables Using SET SET is usually used for setting variables in the fashion that you would see in more procedural languages. Examples of typical uses would be: SET @TotalCost = 10 SET @TotalCost = @UnitCost * 1.1 Notice that these are all straight assignments that use either explicit values or another variable. With a SET, you cannot assign a value to a variable from a query — you have to separate the query from the SET. For example: USE AdventureWorks2008; DECLARE @Test money; SET @Test = MAX(UnitPrice) FROM [Order Details]; SELECT @Test; causes an error, but: USE AdventureWorks2008; DECLARE @Test money; SET @Test = (SELECT MAX(UnitPrice) FROM Sales.SalesOrderDetail); SELECT @Test; works just fine. Although this latter syntax works, by convention, code is never implemented this way. Again, I don’t know for sure why it’s “just not done that way,” but I suspect that it has to do with readability — you want a SELECT statement to be related to retrieving table data, and a SET to be about simple variable assignments. Setting Variables Using SELECT SELECT is usually used to assign variable values when the source of the information you’re storing in the variable is from a query. For example, our last illustration would be typically done using a SELECT: 328 USE AdventureWorks2008; DECLARE @Test money; SELECT @Test = MAX(UnitPrice) FROM Sales.SalesOrderDetail; SELECT @Test; Notice that this is a little cleaner (it takes less verbiage to do the same thing). So again, the convention on when to use which goes like this: ❑ Use SET when you are performing a simple assignment of a variable — where your value is already known in the form of an explicit value or some other variable. ❑ Use SELECT when you are basing the assignment of your variable on a query.

I’m not going to pick any bones about the fact that you’ll see me violate this last convention in many places in this book. Using SET for variable assignment first appeared in version 7.0, and I must admit that nearly a decade after that release, I still haven’t completely adapted yet. Nonetheless, this seems to be something that’s really being pushed by Microsoft and the SQL Server community, so I strongly recommend that you start out on the right foot and adhere to the convention. Reviewing System Functions There are over 30 parameterless system functions available. The older ones in the mix start with an @@ sign — a throwback to when they were commonly referred to as “Global Variables.” Thankfully that name has gone away in favor of the more accurate “system functions,” and the majority of all system functions now come without the @@ prefix. Some of the ones you should be most concerned with are in the table that follows: Variable Purpose Comments @@DATEFIRST Returns what is currently set as the first day of the week (say, Sunday vs. Monday). @@ERROR Returns the error number of the last T- SQL statement executed on the current connection. Returns 0 if no error. @@IDENTITY Returns the last identity value inserted as a result of the last INSERT or SELECT INTO statement. IDENT_CURRENT() Returns the last identity value inserted for a specified table regardless of session or scope. @@OPTIONS Returns information about options that have been set using the SET command. Chapter 11: Writing Scripts and Batches Is a system-wide setting — if someone changes the setting, you may not get the result you expect. Is reset with each new statement. If you need the value preserved, move it to a local variable immediately after the execution of the statement for which you want to preserve the error code. Is set to NULL if no identity value was generated. This is true even if the lack of an identity value was due to a failure of the statement to run. If multiple inserts are performed by just one statement, then only the last identity value is returned. Nice in the sense that it doesn’t get overwritten if you’re inserting into multiple tables, but can give you a value other than what you were expecting if other connections are inserting into the specific table. Since you get only one value back, but can have many options set, SQL Server uses binary flags to indicate what values are set. To test whether the option you are interested is set, you must use the option value together with a bitwise operator. Continued 329

I’m not going to pick any bones about the fact that you’ll see me violate this last convention in many<br />

places in this book. Using SET for variable assignment first appeared in version 7.0, and I must admit<br />

that nearly a decade after that release, I still haven’t completely adapted yet. Nonetheless, this seems to<br />

be something that’s really being pushed by <strong>Microsoft</strong> and the <strong>SQL</strong> <strong>Server</strong> community, so I strongly recommend<br />

that you start out on the right foot and adhere to the convention.<br />

Reviewing System Functions<br />

There are over 30 parameterless system functions available. The older ones in the mix start with an @@<br />

sign — a throwback to when they were commonly referred to as “Global Variables.” Thankfully that<br />

name has gone away in favor of the more accurate “system functions,” and the majority of all system<br />

functions now come without the @@ prefix. Some of the ones you should be most concerned with are in<br />

the table that follows:<br />

Variable Purpose Comments<br />

@@DATEFIRST Returns what is currently<br />

set as the first<br />

day of the week (say,<br />

Sunday vs. Monday).<br />

@@ERROR Returns the error<br />

number of the last T-<br />

<strong>SQL</strong> statement executed<br />

on the current<br />

connection. Returns<br />

0 if no error.<br />

@@IDENTITY Returns the last<br />

identity value<br />

inserted as a result of<br />

the last INSERT or<br />

SELECT INTO statement.<br />

IDENT_CURRENT() Returns the last<br />

identity value<br />

inserted for a specified<br />

table regardless<br />

of session or scope.<br />

@@OPTIONS Returns information<br />

about options that<br />

have been set using<br />

the SET command.<br />

Chapter 11: Writing Scripts and Batches<br />

Is a system-wide setting — if someone changes<br />

the setting, you may not get the result you<br />

expect.<br />

Is reset with each new statement. If you need the<br />

value preserved, move it to a local variable<br />

immediately after the execution of the statement<br />

for which you want to preserve the error code.<br />

Is set to NULL if no identity value was generated.<br />

This is true even if the lack of an identity value<br />

was due to a failure of the statement to run. If<br />

multiple inserts are performed by just one statement,<br />

then only the last identity value is<br />

returned.<br />

Nice in the sense that it doesn’t get overwritten if<br />

you’re inserting into multiple tables, but can give<br />

you a value other than what you were expecting<br />

if other connections are inserting into the specific<br />

table.<br />

Since you get only one value back, but can have<br />

many options set, <strong>SQL</strong> <strong>Server</strong> uses binary flags to<br />

indicate what values are set. To test whether the<br />

option you are interested is set, you must use the<br />

option value together with a bitwise operator.<br />

Continued<br />

329

logo

products

Resources

Company

Terms of service
Privacy policy
Cookie policy
Cookie settings
Imprint
Change language
Made with love in Switzerland
© 2024 Yumpu.com all rights reserved

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!