- Table of Contents
- Microsoft SQL Server Defined
- Microsoft SQL Server Features
- Microsoft SQL Server Administration
- Microsoft SQL Server Programming
- An Outline for Development
- Database Services
- Database Objects: Databases
- Database Objects: Tables
- Database Objects: Table Relationships
- Database Objects: Keys
- Database Objects: Constraints
- Database Objects: Data Types
- Database Objects: Views
- Database Objects: Stored Procedures
- Database Objects: Indexes
- Database Objects: User Defined Functions
- Database Objects: Triggers
- Database Design: Requirements, Entities, and Attributes
- Business Process Model Notation (BPMN) and the Data Professional
- Business Questions for Database Design, Part One
- Business Questions for Database Design, Part Two
- Database Design: Finalizing Requirements and Defining Relationships
- Database Design: Creating an Entity Relationship Diagram
- Database Design: The Logical ERD
- Database Design: Adjusting The Model
- Database Design: Normalizing the Model
- Creating The Physical Model
- Database Design: Changing Attributes to Columns
- Database Design: Creating The Physical Database
- Database Design Example: Curriculum Vitae
- The SQL Server Sample Databases
- The SQL Server Sample Databases: pubs
- The SQL Server Sample Databases: NorthWind
- The SQL Server Sample Databases: AdventureWorks
- The SQL Server Sample Databases: Adventureworks Derivatives
- UniversalDB: The Demo and Testing Database, Part 1
- UniversalDB: The Demo and Testing Database, Part 2
- UniversalDB: The Demo and Testing Database, Part 3
- UniversalDB: The Demo and Testing Database, Part 4
- Getting Started with Transact-SQL
- Transact-SQL: Data Definition Language (DDL) Basics
- Transact-SQL: Limiting Results
- Transact-SQL: More Operators
- Transact-SQL: Ordering and Aggregating Data
- Transact-SQL: Subqueries
- Transact-SQL: Joins
- Transact-SQL: Complex Joins - Building a View with Multiple JOINs
- Transact-SQL: Inserts, Updates, and Deletes
- An Introduction to the CLR in SQL Server 2005
- Design Elements Part 1: Programming Flow Overview, Code Format and Commenting your Code
- Design Elements Part 2: Controlling SQL's Scope
- Design Elements Part 3: Error Handling
- Design Elements Part 4: Variables
- Design Elements Part 5: Where Does The Code Live?
- Design Elements Part 6: Math Operators and Functions
- Design Elements Part 7: Statistical Functions
- Design Elements Part 8: Summarization Statistical Algorithms
- Design Elements Part 9:Representing Data with Statistical Algorithms
- Design Elements Part 10: Interpreting the Data—Regression
- Design Elements Part 11: String Manipulation
- Design Elements Part 12: Loops
- Design Elements Part 13: Recursion
- Design Elements Part 14: Arrays
- Design Elements Part 15: Event-Driven Programming Vs. Scheduled Processes
- Design Elements Part 16: Event-Driven Programming
- Design Elements Part 17: Program Flow
- Forming Queries Part 1: Design
- Forming Queries Part 2: Query Basics
- Forming Queries Part 3: Query Optimization
- Forming Queries Part 4: SET Options
- Forming Queries Part 5: Table Optimization Hints
- Using SQL Server Templates
- Transact-SQL Unit Testing
- Index Tuning Wizard
- Unicode and SQL Server
- SQL Server Development Tools
- The SQL Server Transact-SQL Debugger
- The Transact-SQL Debugger, Part 2
- Basic Troubleshooting for Transact-SQL Code
- An Introduction to Spatial Data in SQL Server 2008
- Performance Tuning
- Practical Applications
- Professional Development
- Application Architecture Assessments
- Business Intelligence
- Tips and Troubleshooting
- Additional Resources
Design Elements Part 4: Variables
Last updated Dec 11, 2009.
In the last three tutorials, I've covered a few basic design elements of good Transact-SQL (T-SQL) coding practices. I’ve explained code documentation and comments, scope, and error handling. In this week's installment, I'll cover a quick introduction to variables.
A variable isn't too difficult to understand. At its simplest, it's just one thing that stands for another. A variable is a container. You’ve used these before, in places like your high-school algebra class: 3x+2=8. You know that “x” can stand for the number 2 in this equation. In T-SQL, the real usefulness is that the value in the variable can be changed in code. Once the variable is created and set, the T-SQL code can alter the value as needed.
Most programming languages have extensive variable handling. SQL Server implements variables at the local level, reserving variables that are available anywhere (called global variables) for itself.
A couple of tutorials back I explained the “scope” aspect of programming. In effect, the scope of a variable is how long it persists, or lasts. It's similar to a coupon: the offer is good either forever, until a certain date, or while supplies last. That's scope.
The T-SQL variables I’lll cover in this tutorial have local scope, meaning that they last until the batch finishes running. Each time a statement completes, for SQL Server it's a new day. I'll show you how that plays out throughout this tutorial.
The process for creating and using T-SQL variables consists of three parts:
- Declare the variable, setting its type
- Populate the variable according to its type
- Use the variable
Starting in SQL Server 2008, this process shortens a bit. I’ll cover more about that in a moment. Everything I show you here works for SQL Server 2000 and higher.
Declaring the Variable
You declare variables and set their type at the same time with the DECLARE statement, at the top of the set of statements (called a batch) you want to run:
DECLARE @TestVariable varchar(30)
Notice that the variable name starts with the @ symbol. This is required for all variables in T-SQL.
On the same line, the data type of the data the variable will hold is set. In programming parlance, this is called being "strongly-typed." Before you can use the variable, you have to set the type, and the data that is placed in the variable must conform to that type. I’ll explain a few of these types in a moment.
Like other programming languages, you can declare two variables at the same time if you want:
DECLARE @TestVariable1 varchar(30), @TestVariable1 varchar(30)
I normally avoid setting variables this way. Declaring multiple variables in the same line buries them in code, making them harder to find. Always program in such a way that makes the code easy to edit and maintain later.
Filling the Variable
After the variable and its type are set, you can fill it with data. Remember the scope issue I spoke about earlier? If you declare a variable and press F5 in Query Analyzer (SQL Server 2000) or SQL Server Management Studio (SQL Server 2005 and higher), the variable is created and then destroyed. Any attempt at filling or using the variable after that will fail, since the batch where the variable is declared is complete. You need to declare it, fill it, and use it before you start a new batch. Every F5, or the word GO after a set of statements, is treated as an individual batch of code.
Depending on the type of variable, the data must be either scalar (single-valued) or non-scalar (multiple values). The variable I've created above takes only one value it's a scalar variable.
You have two methods at your disposal to fill a variable. You can use a SELECT statement or a SET statement. I’ll take that example above and add to it to fill the variable, first with SELECT and then with SET:
DECLARE @TestVariable varchar(30) SELECT @TestVariable = 'White'
And now with SET:
DECLARE @TestVariable varchar(30) SET @TestVariable = 'White'
To see the results, you can issue a print command (remember the scope aspect, that's why I'm declaring it again here):
DECLARE @TestVariable varchar(30) SET @TestVariable = 'White' PRINT @TestVariable GO ------------------------------------------ White
As you can see, both methods work. If you peruse Books Online, you'll see that SET is the best syntax to use most often, although SELECT works in most cases as well. I’ll reference another link at the bottom of this tutorial that deals with topic.
Here's a slightly more complex example of filling a variable with the SET command:
USE pubs; GO DECLARE @TestVariable varchar(30) SET @TestVariable = (SELECT au_lname FROM authors WHERE au_fname = 'Johnson')
In this case, I’ve set the variable to equal the results of a SELECT statement from the pubs database and you can also use a more complex subselect to fill the variable, giving you a great deal of flexibility.
Next I’ll explain the difference between Local and Global variables. I'll discuss Global variables in a moment; first I’ll show you what options you have with Local variables.
There are a few types of local variables. The first group is the data types I've been using for all of the columns in the tables things like int, datetime, char, varchar and so forth. I used the varchar type in my examples a few moments ago.
The important thing to remember about a local variable type is to use the right one for the job. You don't, for instance, want to use a varchar where a char will do, since the varchar type sets aside more RAM than a char. This also holds true for int versus bigint and so on. Study the data types I explained in a previous tutorial to understand where you should use each type. These types are normally used to hold a scalar (single) result like ‘B’, ‘Buck’, ‘Buck Woody’, 123, or 12/05/1985.
Another type of local variable is the table variable. This is a non-scalar variable type, which means it can hold more than one value. The table variable is similar to an array in other programming languages. I'll visit this topic again when I discuss cursors, but here's a simple example:
DECLARE @TableVariable TABLE ( AuthorName varchar (55) NOT NULL ) INSERT INTO @TableVariable SELECT au_fname + ' ' + au_lname FROM authors
In this example I've declared a simple table variable with one column, and filled it with the first and last names of the people in the authors table. Once created, the table variable can be accessed like any other table. Again, the scope is local; when the batch runs, the table variable is destroyed.
There are some restrictions on the types of constraints on these variables, but they can be really handy to perform loop logic.
The neat thing about these variables is that are stored completely in memory. When the batch finishes, they are gone. No I/O necessary! Unless, of course, the server is out of memory, and then of course the whole thing is stored in TEMPDB on the hard drive.
I've saved the global variables for last. These variables are prefaced with two @ symbols, like this: @@VERSION. There are several of these, and rather than reproduce them here, I'll let you use your newfound Books Online skills to navigate the "Index" tab and type @@ in the search bar. You'll see several.
Global variables are a special case, in that they don't have local scope, and you can't set them. They are available throughout the system in any database and can be used to determine the current date, the version of the server, and more. Another interesting fact about global variables is that they can be used to set the value of a local variable!
To use a global variable, just SELECT it:
SELECT @@VERSION GO
Using the Variable
Now that you've created and populated the local variable, you can use it. Here’s a simple example of using a variable as a comparison value in another query:
DECLARE @TestVariable varchar(30) SET @TestVariable = 'White' SELECT * FROM authors WHERE au_lname = @TestVariable
You’ll see this used for variables quite often in code, especially in Stored Procedures. Here's an example that demonstrates a loop using a variable:
-- Declare a variable of type int DECLARE @TestVariable int -- Make that variable equal to 1 SET @TestVariable = 1 -- Set up a loop WHILE @TestVariable < 15 -- The work part of the loop goes in between the begin and end statements BEGIN -- Show the value of the variable PRINT @TestVariable /* Take the variable (on the right) and add one to it, and then make the new value (on the left) equal to that */ SET @TestVariable = @TestVariable + 1 /* Go back to the top of the loop (the WHILE part) and see if the new value is less than 15. If so, keep going. */ END
A simple example, no doubt, but an adjustment to fill the initial variable with something meaningful (perhaps from another query) and a change between the BEGIN and END markers would make this a useful bit of code.
In future articles, I'll make heavy use of variables. I'll also apply these same concepts to stored procedures and cursors.
InformIT Articles and Sample Chapters
Can't wait to learn more about loops and cursors? Check out Optimizing Transact-SQL Code, by Kevin Kline and Baya Pavliashvili. They show you the best way to use variables in writing cursors.
Books and eBooks
SQL Server variables are covered in more depth in Teach Yourself SQL in One Hour a Day.
SET and SELECT have different results, based on what you need to do. This article covers more about that.