Trigers SP Views

Implementing Stored Procedures
About This Chapter

Stored procedures improve database performance, enhance database security, and
bring programming techniques to Transact-SQL not available without this database
object. This chapter introduces you to the types of stored procedures available in
SQL Server 2000 and how to create, execute, and alter them. The final lesson in
this chapter introduces you to programming stored procedures.
Before You Begin

To complete the lessons in this chapter, you must have:
SQL Server 2000 Enterprise Edition installed on a Microsoft Windows 2000
Server computer.
The ability to log on to the Windows 2000 Server computer and to SQL Server
as the Windows 2000 Administrator.
Completed the exercises in Chapter 3, Designing a SQL Server Database,
Chapter 4, Implementing SQL Server Databases and Tables, and Chapter 5,

Implementing Data Integrity.
268 Part 1: Self-Paced Training Kit for Microsoft SQL Server 2000 Database Design and
Implementation
Lesson 1: Introduction to Stored

Procedures
In Chapters 3 through 7, you used Query Analyzer to create, execute, and save
Transact-SQL commands and batches of commands as scripts written using
Transact-SQL language. When the scripts are executed, the commands within them
are processed by SQL Server to display result sets, to administer SQL Server, and
to manipulate data contained in a database. When the scripts are saved, they are
stored in the file system and are commonly given a SQL extension. Alternatively,
Transact-SQL scripts can be named and saved in SQL Server as stored procedures.
You can then invoke stored procedures in a number of ways, such as through Query
Analyzer, in order to process the Transact-SQL statements within them.
In previous chapters, you used a number of stored procedures (such as sp_help and
sp_helpconstraint). These procedures are stored in the Master database and contain
Transact-SQL commands that make it easy for you to view various properties of
objects in the database.
After this lesson, you will be able to:
Describe the purpose and reasons for using stored procedures.
Explain how SQL Server processes a stored procedure.
Determine when to use stored procedures to complete SQL Server tasks.
Estimated Lesson time: 30 minutes
Purpose and Advantages of Stored Procedures

Stored procedures provide performance benefits, a programming framework, and
security features unavailable to Transact-SQL commands sent to the server for processing.
Performance is enhanced through local storage (local to the database), precompiling
the code, and caching. A programming framework is provided through
common programming constructs such as input and output parameters and procedure
reuse. Security features include encryption and privilege limits that keep users
away from the underlying database structure while still enabling them to run stored
procedures that act on the database.
Performance
Every time a Transact-SQL command (or batch of commands) is sent to the server
for processing, the server must determine whether the sender has appropriate permissions
to execute the commands and whether the commands are valid. Once the
permissions and the syntax are verified, SQL Server builds an execution plan to
process the request.
Chapter 8 Implementing Stored Procedures 269
Stored procedures are more efficient in part because the procedure is stored in SQL
Server when it is created. Therefore, the content in the procedure runs at the server
when the stored procedure is executed. A complex Transact-SQL script contained
in a stored procedure is called by a single Transact-SQL statement, rather than by
sending hundreds of commands over the network.
Before a stored procedure is created, the command syntax is checked for accuracy.
If no errors are returned, the procedures name is stored in the SysObjects table and
the procedures text is stored in the SysComments table. The first time the stored
procedure is run, an execution plan is created and the stored procedure is compiled.
Subsequent processing of the compiled stored procedure is faster because SQL
Server does not recheck command syntax, re-create an execution plan, or recompile
the procedure. The cache is checked first for an execution plan before a new
plan is created.
Note The relative performance boost provided by placing stored procedure execution
plans in the procedure cache is reduced because execution plans for all SQL
statements are now stored in the procedure cache. A Transact-SQL statement will
attempt to use an existing execution plan if possible.
Programming Framework
Once a stored procedure is created, you can call it whenever its needed. This feature
provides modularity and encourages code reuse. Code reuse increases the maintainability
of a database by insulating the database from changing business practices. If
business rules change in an organization, a stored procedure can be modified to
comply with the new business rules. All applications that call the stored procedure
will then comply with the new business rules without direct modification.
Like other programming languages, stored procedures can accept input parameters,
return output parameters, provide execution feedback in the form of status codes
and descriptive text, and call other procedures. For example, a stored procedure can
return a status code to a calling procedure so that the calling procedure performs an
operation based on the code received.
Software developers can write sophisticated programs in a language such as Visual
C++; then, a special type of stored procedure called an extended stored procedure
can be used to invoke the program from within SQL Server.
You should write a stored procedure to complete a single task. The more generic
the stored procedure, the more useful it will be to many databases. For example,
the sp_rename stored procedure changes the name of a user-created object, such
as a table, a column, or a user-defined data type in the current database. Thus, you
can use sp_rename to rename a table in one database or a table column in another
database.
Implementation
Security
Another important feature of stored procedures is that they enhance security
through isolation and encryption. Database users can be given permission to execute
a stored procedure without being granted permissions to directly access the
database objects on which the stored procedure operates. Additionally, a stored
procedure can be encrypted when it is created or modified so that users are unable
to read the Transact-SQL commands in the stored procedure. These security features
insulate the database structure from the database user, which further ensures
data integrity and database reliability.
Categories of Stored Procedures

There are five classes of stored procedures: system stored procedures, local stored
procedures, temporary stored procedures, extended stored procedures, and remote
stored procedures. There are other ways to categorize stored procedures, but this
organization into five groups makes it easy to identify the stored procedures location,
purpose, and capability.
System Stored Procedures

System stored procedures are stored in the Master database and are typically
named with an sp_ prefix. They perform a wide variety of tasks to support SQL
Server functions (such as catalog procedures) that support external application
calls for data in the system tables, general system procedures for database administration,
and security management functions. For example, you can view table privileges
by using the sp_table_privileges catalog stored procedure. The following
statement uses the sp_table_privileges system stored procedure to show privileges
to the Stores table in the Pubs database:
USE Pubs
GO
EXECUTE sp_table_privileges Stores
A common database administration task is viewing information about current database

users and processes. This step is an important one before a database is shut
down. The following statement uses the sp_who system stored procedure to display
all processes in use by the LAB1\Administrator user:
EXECUTE sp_who @loginame=LAB1\Administrator
Database security is critical to most organizations that store private data in a database.
The following statement uses the sp_validatelogins system stored procedure
to show any orphaned Windows NT or Windows 2000 user and group accounts that
no longer exist but still have entries in the SQL Server system tables:
EXECUTE sp_validatelogins
There are hundreds of system stored procedures included with SQL Server. For a
complete list of system stored procedures, refer to System Stored Procedures in
SQL Server Books Online. You will notice in the system stored procedures reference
that some extended stored procedures are listed. Extended stored procedures
are discussed later in this lesson.
Local Stored Procedures

Local stored procedures are usually stored in a user database and are typically
designed to complete tasks in the database in which they reside. A local stored procedure
might also be created to customize system stored procedure code. To create
a custom task based on a system stored procedure, first copy the contents of a system
stored procedure and save the new stored procedure as a local stored procedure.
You will create local stored procedures for the BookShopDB database in
Exercise 3.
Temporary Stored Procedures

A temporary stored procedure is similar to a local stored procedure, but it exists
only until either the connection that created it is closed or SQL Server is shut down.
The stored procedure is deleted at connection termination or at server shutdown,
depending on the type of temporary stored procedure created. This volatility exists
because temporary stored procedures are stored in the TempDB database. TempDB
is re-created when the server is restarted; therefore, all objects within this database
disappear upon shutdown. Temporary stored procedures are useful if you are
accessing earlier versions of SQL Server that do not support the reuse of execution
plans and if you dont want to store the task because the same task will be executed
with many different parameter values.
There are three types of temporary stored procedures: local (also called private),
global, and stored procedures created directly in TempDB. A local temporary
stored procedure always begins with #, and a global temporary stored procedure
always begins with ##. Lesson 2 explains how to create each type of temporary
stored procedure. The execution scope of a local temporary procedure is limited to
the connection that created it. All users who have connections to the database, however,
can see the stored procedure in the Object Browser window of Query Analyzer.
Because of its limited scope, there is no chance of name collision between
other connections that are creating temporary stored procedures. To ensure uniqueness,
SQL Server appends the name of a local temporary stored procedure with a
series of underscore characters and a connection number unique to the connection.
Privileges cannot be granted to other users for the local temporary stored procedure.
When the connection that created the temporary stored procedure is closed,
the procedure is deleted from TempDB.
Any connection to the database can execute a global temporary stored procedure.
This type of procedure must have a unique name, because all connections can execute
the procedure and, like all temporary stored procedures, it is created in

Implementation
TempDB. Permission to execute a global temporary stored procedure is automatically

granted to the public role and cannot be changed. A global temporary stored
procedure is almost as volatile as a local temporary stored procedure. This procedure
type is removed when the connection used to create the procedure is closed
and any connections currently executing the procedure have completed.
Temporary stored procedures created directly in TempDB are different from local
and global temporary stored procedures in the following ways:
You can configure permissions for them.
They exist even after the connection used to create them is terminated.
They arent removed until SQL Server is shut down.
Because this procedure type is created directly in TempDB, it is important to fully

qualify the database objects referenced by Transact-SQL commands in the code.
For example, you must reference the Authors table, which is owned by dbo in the
Pubs database, as pubs.dbo.authors.
Extended Stored Procedures

An extended stored procedure uses an external program, compiled as a 32-bit
dynamic link library (DLL), to expand the capabilities of a stored procedure. A
number of system stored procedures are also classified as extended stored procedures.
For example, the xp_sendmail program, which sends a message and a query
result set attachment to the specified e-mail recipients, is both a system stored procedure
and an extended stored procedure. Most extended stored procedures use the
xp_ prefix as a naming convention. However, there are some extended stored procedures
that use the sp_ prefix, and there are some system stored procedures that
are not extended and use the xp_ prefix. Therefore, you cannot depend on naming
conventions to identify system stored procedures and extended stored procedures.
Use the OBJECTPROPERTY function to determine whether a stored procedure is
extended or not. OBJECTPROPERTY returns a value of 1 for IsExtendedProc,
indicating an extended stored procedure, or returns a value of 0, indicating a stored
procedure that is not extended. The following examples demonstrate that
sp_prepare is an extended stored procedure and that xp_logininfo is not an
extended stored procedure:
USE Master
--an extended stored procedure that uses an sp_ prefix.
SELECT OBJECTPROPERTY(object_id(sp_prepare), IsExtendedProc)
This example returns a value of 1.

USE Master
--a stored procedure that is not extended but uses an xp_ prefix
SELECT OBJECTPROPERTY(object_id(xp_logininfo), IsExtendedProc)
This example returns a value of 0.
Remote Stored Procedures

As the name suggests, a remote stored procedure executes a stored procedure on a
remote SQL Server installation. Remote stored procedures remain for backward
compatibility but have been replaced by distributed queries. For information about
distributed queries, refer to Chapter 7, Managing and Manipulating Data.
Exercise 1: Exploring Stored Procedures

In this exercise, you will view a number of system stored procedures contained in
the Master database. To perform this exercise, you should be logged in to your
Windows 2000 Server computer as Administrator.
_
To view system stored procedures in the Master database
1. Open Query Analyzer and connect to your local server.

2. Open the Object Browser window if it is not already displayed.
The Object Browser window displays a hierarchical tree of database objects.
3. Expand the master node.
A list of object types appears. Notice the Stored Procedures and Extended Procedures
nodes.
4. Expand the Stored Procedures node.
A list of stored procedures and extended stored procedures in the Master database
appears.
5. Review the names of the listed procedures. Notice that dbo owns all of the procedures.
How can you tell the difference between a system stored procedure and an
extended stored procedure from the list of procedures that appear below the
Stored Procedures node?
6. Expand the dbo.sp_who system stored procedure.
The Parameters and Dependencies nodes appear.
7. Expand the Parameters node.
Notice that there are two parameters defined for this procedure:
@RETURN_VALUE and @loginame. @RETURN_VALUE is built-in and is
used to supply return codes. All stored procedures contain the
@RETURN_VALUE parameter; @loginame is an input parameter. The second

example code listed under the System Stored Procedures section in this lesson
sets the @loginame equal to LAB1\Administrator.
Implementation
8. Expand the Dependencies node.

Notice that there is a single dependency for this stored procedure: the
dbo.sysprocesses table. This is a system table stored in the Master database.
The sp_who system stored procedure queries the SysProcesses table and displays
parts of this table in its result set. You can find this table by expanding the
System Tables node.
9. If you examined the dbo.sysprocesses table in the previous step, return to the
sp_who system stored procedure in the Object Browser.
10. Scroll down in the Object Browser until you see the Extended Procedures node.
Notice that right above the Extended Procedures node, there are three stored
procedures beginning with the xp_ prefix. These are not extended stored procedures.
You can verify this fact by running the OBJECTPROPERTY function
described in the lesson against them.
11. Expand the Extended Procedures node.
As you scroll through the objects contained in this node, notice that both system
stored procedures and extended stored procedures exist. The majority of
procedures under this node are extended stored procedures.
12. Keep Query Analyzer open for the next exercise.
_
To use two methods for viewing the contents of a stored procedure
1. Click once on the dbo.sp_who object.

2. Right-click dbo.sp_who.
The context menu for this object appears.
3. Click Scripting Options.
The Options dialog box appears.
4. Click the Include Descriptive Headers In The Script check box and click OK.
This option will display the stored procedure name and its create date near the
top of the text contained in the procedure.
5. Right-click dbo.sp_who.
The context menu for this object appears.
6. Point to Script Object To New Window As and click Create.
The dbo.sp_who stored procedure appears in the Query window.
Notice that the CREATE PROCEDURE keywords appear near the top of the
file. In the next lesson, you will learn more about creating stored procedures
using Transact-SQL. Notice that batches of commands are specified in the
stored procedure text. As you examine the text, you will see that the @loginame
input parameter appears in a number of places. Notice also that the
SysProcesses table is queried a number of times in the stored procedure using
its fully qualified name, master.dbo.sysprocesses.
Dont worry about not understanding everything in this stored procedure. In

Lessons 2 and 3, you will learn more about how to manage and program stored
procedures.
7. Click New Query on the toolbar or press CTRL+N.
A new query window appears in the right pane.
8. In the Editor pane of the Query window, enter the following Transact-SQL
code:
sp_helptext [master.dbo.sp_who]
This code uses the sp_helptext system stored procedure to show the contents of
the sp_who system stored procedure contained in the Master database. It is not
necessary to fully qualify the name of the stored procedure, but it is a good
practice because it guarantees that you will open the object that you are interested
in viewing.
9. Execute the code.
The Grids tab of the Results pane displays the contents of the sp_who system
stored procedure.
Lesson Summary
Stored procedures contain Transact-SQL commands that are stored in a database
and are typically designed to run a single task. Stored procedures provide performance
gains, programming capabilities, and security features not available when
using individual Transact-SQL commands or batches. Storing the procedure in a
database, checking the syntax when the procedure is created, and creating a reusable
execution plan the first time the stored procedure is executed will enhance performance.
Stored procedures support parameters and return codes. Because stored
procedures are modular, they provide a layer of insulation between changing business
practices and the underlying database. The programming capabilities of stored
procedures are nearly unlimited because of support for extended stored procedures.
From a security perspective, users can be granted the right to execute a stored procedure
without being granted the right to manipulate the database outside the
stored procedure.
There are five general categories of stored procedures: system, local, temporary,
extended, and remote. SQL Server includes hundreds of system stored procedures
and extended stored procedures to perform tasks such as system administration.
Local stored procedures are created in a user database and are typically used to
complete tasks specific to the database in which they are created. Temporary stored
procedures look and act like any of the other categories of stored procedures, but
they are volatile and disappear upon the termination of a user connection (or when
the server is shut down). Remote stored procedures are available for backward
compatibility but have been replaced by distributed queries.
Implementation
Lesson 2: Creating, Executing,

Modifying, and
Deleting Stored Procedures
In this lesson, you will learn a number of methods for managing stored procedures.
Stored procedures are commonly created, executed, modified, or deleted using
Query Analyzer or Enterprise Manager.
Stored procedures can be created before the objects that they reference are created.
This feature is called deferred name resolution. The keywords used to create a procedure
are CREATE PROCEDURE.
Before running a stored procedure, you must provide any required parameter values.
Stored procedures can be executed manually or automatically when SQL
Server starts. The keyword used to run a procedure is EXECUTE. This keyword is
optional if the procedure to run is a single line of code or if the procedure name is
the first word in a batch.
Modifying a stored procedure after it is created is common practice; perhaps you
need to add a parameter or change some other part of the code in the procedure.
Modifying a procedure, rather than deleting it and recreating it, is a time-saver,
because many of the stored procedure properties (such as permissions) are retained
when a procedure is modified. The keywords used to modify a procedure are

ALTER PROCEDURE.
Procedures are dropped from a database with the DROP keyword. You can drop a
stored procedure from Enterprise Manager or Query Analyzer by selecting the
stored procedure and pressing the DELETE key. A procedure shouldnt be deleted
until other objects that depend on the procedure are removed or modified (to break
their dependency).
Create and modify a stored procedure in SQL Server.
Execute a stored procedure.
Delete a stored procedure from SQL Server.
Estimated lesson time: 45 minutes
How a Procedure Is Stored

When a procedure is created, SQL Server checks the syntax of the Transact-SQL
statements within it. If the syntax is incorrect, SQL Server will generate a syntax
incorrect error message, and the procedure will not be created. If the procedures
text passes syntax checking, the procedure is stored by writing its name and other
information (such as an auto-generated identification number) to the SysObjects

table. The text used to create the procedure is written to the SysComments table of
the current database.
The following SELECT statement queries the SysObjects table in the Pubs database
to show the identification number of the ByRoyalty stored procedure:
SELECT [name], [id] FROM [pubs].[dbo].[SysObjects]
WHERE [name] = byroyalty
This query returns the following:

Using the information returned from the SysObjects table, the next SELECT statement
queries the SysComments table by using the identification number of the
ByRoyalty stored procedure:
SELECT [text] FROM [pubs].[dbo].[SysComments]
WHERE [id] = 581577110
This query returns the create text of the ByRoyalty stored procedure, whose identification
number is 581577110.
Note The two previous SELECT statements could have been consolidated into a
single SELECT statement by using a JOIN. They are separated here for simplicity
and clarity.
Using the sp_helptext system stored procedure is a better option for displaying the
text used to create an object (such as an unencrypted stored procedure), because
the text is returned in multiple rows. You used the sp_helptext stored procedure in
the last practice of Exercise 1.
Methods for Creating Stored Procedures

SQL Server provides several methods that you can use to create a stored procedure:
the Transact-SQL CREATE PROCEDURE statement, SQL-DMO (using the
StoredProcedure object), the console tree in Enterprise Manager, and the Create
Stored Procedure wizard (which you can access through Enterprise Manager).
Note Many of the commands explored here and in other chapters are accessible
through the SQL-DMO API. An exploration of SQL-DMO is beyond the scope of
this training kit, however. Refer to SQL Server Books Online for more information
about SQL-DMO.
name id
Byroyalty 581577110
Implementation
The CREATE PROCEDURE Statement

You can use the CREATE PROCEDURE statement or the shortened version of the
statement, CREATE PROC, to create a stored procedure in Query Analyzer or in a
command-prompt tool such as osql. When using CREATE PROC, you can perform
the following tasks:
Specify grouped stored procedures
Define input and output parameters, their data types, and their default values
When input and output parameters are defined, they are always preceded by the
at sign (@), followed by the parameter name and then a data type designation.
Output parameters must include the OUTPUT keyword to distinguish them
from input parameters.
Use return codes to display information about the success or failure of a task
Control whether an execution plan should be cached for the procedure
Encrypt the stored procedures content for security
Control execution behavior for a replication subscriber
Specify the actions that the stored procedure should take when executed
Note Lesson 3 explores input and output parameters, programming actions that a
stored procedure should take when executed, and success or failure result sets. For
additional syntax details concerning CREATE PROC, refer to the Transact-SQL

reference in SQL Server Books Online.
Providing a Stored Procedure with Context

With the exception of temporary stored procedures, a stored procedure is always
created in the current database. Therefore, you should always specify the current
database by using the USE database_name statement followed by the GO batch
command before creating a stored procedure. You can also use the Change Database
drop-down list box in Query Analyzer to select the current database.
The following script selects the Pubs database in the first batch and then creates a
procedure named ListAuthorNames, which dbo owns:
USE Pubs
GO
CREATE PROCEDURE [dbo].[ListAuthorNames]
AS
SELECT [au_fname], [au_lname] FROM [pubs].[dbo].[authors]
Notice that the procedure name is fully qualified in the example. A fully qualified
stored procedure name includes the procedures owner (in this case, dbo) and the
name of the procedure, ListAuthorNames. Specify dbo as the owner if you want to
ensure that the task in the stored procedure will run regardless of table ownership
in the database. The database name is not part of a fully qualified stored procedure
name when using the CREATE PROCEDURE statement.
Creating Temporary Stored Procedures

To create a local temporary stored procedure, append the procedure name with #
when you create it. This pound sign instructs SQL Server to create the procedure in
TempDB. To create a global, temporary stored procedure, append the procedure
name with ## when it is created. This double pound sign instructs SQL Server to
create the procedure in TempDB. SQL Server ignores the current database when
creating a temporary stored procedure. By definition, a temporary stored procedure
can only exist in TempDB. To create a temporary stored procedure directly in
TempDB that is not a local or global temporary stored procedure, make TempDB
the current database and then create the procedure. The following examples create
a local temporary stored procedure, a global temporary stored procedure, and a
stored procedure directly in TempDB:
--create a local temporary stored procedure.
CREATE PROCEDURE #localtemp
AS
SELECT * from [pubs].[dbo].[authors]

GO
--create a global temporary stored procedure.
CREATE PROCEDURE ##globaltemp
AS
GO
--create a temporary stored procedure that is local to tempdb.
USE TEMPDB
GO
CREATE PROCEDURE directtemp
AS
GO
Fully qualified database names are specified in the SELECT statements. If the procedure
is not executed in the context of a specific database and the Transact-SQL
commands in the stored procedure are database-specific, then fully qualified database
names ensure that the proper database is referenced.
In the third example, when creating a temporary stored procedure directly in
TempDB, you must make TempDB the current database (USE TempDB) before
executing it, or you must fully qualify its name ([TempDB].[dbo].[directtemp]).
Like system stored procedures in the Master database, local and global temporary
stored procedures are available for execution using their short names (regardless of
the current database).
Implementation
Grouping, Caching, and Encrypting Stored Procedures

Stored procedures can be logically tied together by grouping them upon creation.
This technique is useful for stored procedures that should be administered as a single
unit and are used in a single application. To group stored procedures, you
assign each procedure in the group the same name and append the name with a
semicolon and a unique number. For example, naming the following two stored
procedures GroupedProc;1 and GroupedProc;2 on creation logically groups them
together. When you view the contents of GroupedProc, you will see the code for
both GroupedProc;1 and GroupedProc;2.
By default, a stored procedures execution plan is cached the first time it is executed,
and it isnt cached again until the server is restarted or until an underlying
table used by the stored procedure changes. For performance reasons, you might
not want to cache an execution plan for a stored procedure. For example, when a
stored procedures parameters vary considerably from one execution to the next,
caching an execution plan is counterproductive. To cause a stored procedure to be
recompiled every time it is executed, add the WITH RECOMPILE keywords when
the stored procedure is created. You can also force a recompile by using the
sp_recompile stored procedure or by specifying WITH RECOMPILE when the
procedure is executed.
Encrypting a stored procedure protects its contents from being viewed. To encrypt
a stored procedure, use the WITH ENCRYPTION keywords when creating the
procedure. For example, the following code creates an encrypted procedure named
Protected:
USE Pubs
GO
CREATE PROC [dbo].[protected] WITH ENCRYPTION
AS
SELECT [au_fname], [au_lname] FROM [pubs].[dbo].[authors]
The WITH ENCRYPTION keywords encrypt the procedures text column in the
SysComments table. A simple way to determine whether a procedure is encrypted
is by using the OBJECTPROPERTY function
-check if stored procedure is encrypted and if so, return 1 for IsEncrypt
ed
SELECT OBJECTPROPERTY(object_id(protected), IsEncrypted)
or by calling the procedure with sp_helptext:

--if the stored procedure is encrypted, return
The object comments have been encrypted."
EXEC sp_helptext protected
Note An encrypted stored procedure cannot be replicated. After a stored procedure

is encrypted, SQL Server decrypts it for execution. However, its definition
cannot be decrypted for viewing by anyone, including the owner of the stored procedure.
Therefore, make sure to place an unencrypted version of the stored procedure
definition in a secure location. If the procedure needs to be modified, edit the
contents of the unencrypted stored procedure and save it to the secure location.
Then, use the ALTER PROCEDURE statement with encryption to modify the existing
encrypted stored procedure. You will learn about the ALTER PROCEDURE
statement later in this lesson.
Enterprise Manager
You can create a stored procedure directly in Enterprise Manager. To accomplish
this task, expand the console tree for your server and then expand the database
where a stored procedure should be created. Right-click the Stored Procedure node,
and then click New Stored Procedure. When the Stored Procedure Properties - New
Stored Procedure dialog box appears, enter the contents of the stored procedure.
Figure 8.1 shows the Stored Procedure Properties - New Stored Procedure dialog
box that contains the code from a previous example.
F08BQ01.eps
Figure 8.1. The General tab of the Stored Procedure Properties - New Stored Procedure
dialog box for a new stored procedure.
You can also check the syntax of the stored procedure before creating it and save a
template that will always appear when you create a new stored procedure by using
Enterprise Manager. Once the procedure is created, you can open the properties of
the procedure and configure permissions. By default, the stored procedures owner
and sysadmins have full permission to the stored procedure.
Implementation
Templates are useful because they provide a framework for creating consistent
documentation
for stored procedures. Typically, text is added to the header of the template
that describes how each stored procedure should be documented.
Create Stored Procedure Wizard

The Create Stored Procedure wizard walks you through the steps necessary to create
a new stored procedure. You can access the wizard by selecting Wizards from
the Tools menu. In the Select Wizard window, expand the Database option, then
select the Create Stored Procedure Wizard and click OK. From there, you complete
the steps in the wizard. Figure 8.2 shows the options on the Welcome to the Create
Stored Procedure wizard screen that you specify when you run the Create Stored
Procedure wizard.
F08BQ02.eps
Figure 8.2. The Welcome to the Create Stored Procedure Wizard screen.
The Create Stored Procedure wizard enables you to create procedures that insert,
delete, or update data in tables. To modify the stored procedure that the wizard
creates, you can edit it within the wizard or by using other tools (such as Query
Analyzer).
Creating and Adding Extended Stored Procedures

After creating an extended stored procedure, you must register it with SQL Server.
Only users who have the sysadmin role can register an extended stored procedure
with SQL Server. To register the extended stored procedure, you can use the
sp_addextendedproc system stored procedure in Query Analyzer or use Enterprise
Manager. In Enterprise Manager, expand the Master database, right-click the
Extended Stored Procedures node, and then click New Extended Stored Procedure.
Extended stored procedures can be added only to the Master database.
Deferred Name Resolution

When a stored procedure is created, SQL Server does not check for the existence of
any objects that are referenced in it. This feature exists because its possible that an
object, such as a table referenced in the stored procedure, does not exist when the
stored procedure is created. This feature is called deferred name resolution. Object
verification occurs when the stored procedure is executed.
When referring to an object (such as a table) in a stored procedure, make sure to
specify the owner of the object. By default, SQL Server assumes that the creator of
the stored procedure is also the owner of the objects referenced in the procedure.
To avoid confusion, consider specifying dbo as the owner when creating all objects
(both stored procedures and objects referenced in the stored procedures).
Executing a Stored Procedure

As you have seen in previous lessons, you can run a stored procedure in Query
Analyzer simply by typing its name and any required parameter values. For example,
you viewed the contents of a stored procedure by typing sp_helptext and the
name of the stored procedure to be viewed. The name of the stored procedure to be
viewed is the parameter value.
If the stored procedure isnt the first statement in a batch, in order to run it you
must precede the name of the stored procedure with the EXECUTE keyword or
with the shortened version of the keyword, EXEC.
Calling a Stored Procedure for Execution

When you specify the procedure name, the name can be fully qualified, such as
[database_name].[owner].[procedure_name]. Or, if you make the database containing
the stored procedure the current database (USE database_name), then you
can execute the procedure by specifying [owner].[procedure_name]. If the
0000000procedure name is unique in the active database, you can simply specify
[procedure_name].
Note The identifiers ( [ ] ) that appear in an object name are included here for
clarity and are used in the examples even when the object names do not violate the
rules for identifiers. Refer to Chapter 2, Using Transact-SQL on a SQL Server
Database (Lesson 3) for details.
Fully qualified names are not necessary when executing system stored procedures
that have an sp_ prefix, local temporary stored procedures, or global temporary
stored procedures. SQL Server will search the Master database for any stored procedures
that have an sp_ prefix where dbo is the owner. To avoid confusion, do not
name local stored procedures with the same names as stored procedures located in
the Master database. If you do name a local stored procedure with the same name
as a system stored procedure, make sure to append the procedure name with an
Implementation
owner other than dbo. SQL Server does not automatically search the Master database
for extended stored procedures. Therefore, either fully qualify the name of an
extended stored procedure or change the active database to the location of the
extended stored procedure.
Specifying Parameters and Their Values

If a stored procedure requires parameter values, you must specify them when executing
the procedure. When input and output parameters are defined, they are preceded
by the at sign (@), followed by the parameter name and the data type
designation. When they are called for execution, you must include a value for the
parameter (and optionally, the parameter name). The next two examples run the
au_info stored procedure in the Pubs database with two parameters: @lastname
and @firstname:
--call the stored procedure with the parameter values.
USE Pubs
GO
EXECUTE au_info Green, Marjorie
--call the stored procedure with parameter names and values.
USE Pubs
GO
EXECUTE au_info
@lastname = Green, @firstname = Marjorie
In the first example, the parameter values were specified but the parameter names
were not. If the values are specified without their corresponding names, the values
must be called in the same order as they were specified when the procedure was
created. In the second example, the parameter names and values were specified.
When both the names and the values are specified, they can be listed in any order.
Parameters assigned default values when a stored procedure is created might run
successfully without specifying a value upon execution.
The following list shows some of the optional syntax available when executing
stored procedures:
A return code variable of integer data type to store values returned from the
stored procedure
The RETURN keyword with an integer value (or values) must be specified in
the stored procedure for this optional variable to work.
A semicolon followed by a group number
For grouped stored procedures, you can either execute all stored procedures in
the group by simply specifying the stored procedure name, or you can include a
number to select which procedure in the group you wish to execute. For example,
if you create two stored procedures named GroupedProc;1 and
GroupedProc;2, you can run both of the stored procedures by typing EXEC
groupedproc. Or, you can run procedure 2 by typing EXEC groupedproc;2.
If parameter names are defined in grouped stored procedures, each parameter

name must be unique to the group. Parameter values are then specified in
grouped stored procedures in the same way that they are specified when running
individual stored procedures.
Variables to hold the parameters defined in the stored procedure
Variables are defined by using the DECLARE keyword before using EXECUTE.
You will work with variables in Exercise 3.
Note For additional syntax details about EXECUTE, refer to the Transact-SQL
reference in SQL Server Books Online.
Executing Stored Procedures when SQL Server Starts

For performance, administration, or background task completion, you can mark
stored procedures to run when SQL Server starts by using the sp_procoption stored
procedure. This procedure accepts three parameters: @ProcName, @OptionName,
and @OptionValue. The following statement configures a procedure named
AutoStart to start automatically:
USE Master
GO
EXECUTE sp_procoption
@procname = autostart,
@optionname = startup,
@optionvalue = true
Only procedures owned by dbo and located in the Master database can be configured
to start automatically. To automatically start procedures in other databases,
you can call them from a procedure located in the Master database that is configured
to start automatically. Calling one procedure from another is called nesting.
You can configure a stored procedure to start automatically by using Enterprise
Manager. Access the Master database, then click the Stored Procedures node.
Select a stored procedure that you wish to start automatically, and then right-click
it. On the properties dialog box of the stored procedure, select the Execute Whenever
SQL Server Starts check box.
To determine whether a procedure is set to start automatically, run the OBJECTPROPERTY
function and check the ExecIsStartup property. For example, the following
code checks to determine whether the AutoStart stored procedure is
configured to start automatically:
USE Master
--determine whether a stored procedure is set to start automatically
SELECT OBJECTPROPERTY(object_id(autostart), ExecIsStartup)
Implementation
To disable stored procedures from starting automatically, you can run the
sp_configure stored procedure. The following statement configures SQL Server so
that stored procedures flagged to start automatically will not be started the next
time SQL Server is started:
EXECUTE sp_configure
@configname = scan for startup procs, @configvalue = 0
RECONFIGURE
GO
Modifying Stored Procedures

You can use the ALTER PROCEDURE statement or the shortened version of this
statement, ALTER PROC, to modify the contents of a user-defined stored procedure
by using Query Analyzer or a command-prompt tool such as osql. The ALTER
PROCEDURE syntax is nearly identical to the CREATE PROCEDURE syntax.
The value of using ALTER PROCEDURE rather than deleting the procedure and
recreating it is that ALTER PROCEDURE retains most of the procedures properties,
such as its object ID, the permissions set for the procedure, and its startup flag.
To retain encryption or recompile settings, you must specify them (WITH
ENCRYPTION and/or WITH RECOMPILE keywords) when running the ALTER

PROCEDURE statement.
You can use Enterprise Manager and Query Analyzer to alter user-defined stored
procedures. In Enterprise Manager, right-click a user-defined stored procedure and
then click Properties. In the Stored Procedure Properties dialog box, modify the
stored procedure statements appearing in the Text box, and then click OK. Using
Query Analyzer, right-click a user-defined stored procedure and click Edit or point
to Script Object to New Window As, and then click Alter. After altering the text,
execute the stored procedure.
To modify the name of a user-defined stored procedure, use the sp_rename stored
procedure. The following statement renames the ByRoyalty stored procedure to
RoyaltyByAuthorID:
USE PUBS
GO
EXECUTE sp_rename
@objname = byroyalty, @newname = RoyaltyByAuthorID,
@objtype = object
User-defined stored procedures can be renamed in Enterprise Manager by rightclicking

the stored procedure name and clicking Rename.
You should exercise caution when renaming stored procedures and other objects
(such as tables). Stored procedures can be nested. If a call is made to a renamed
object, the original stored procedure will be incapable of locating the object.
Deleting Stored Procedures

You can use the DROP PROCEDURE statement or the shortened version of this
statement, DROP PROC, to delete a user-defined stored procedure, several procedures
at once, or a set of grouped procedures. The following statement drops two
procedures in the Pubs database: Procedure01 and Procedure02:
USE pubs
GO
DROP PROCEDURE procedure01, procedure02
Notice in the example that Pubs was made the current database. You cannot specify
the database name when specifying a procedure to drop. The fully qualified name
of the procedure is [owner].[procedure_name]. If you have created a user-defined
system stored procedure (sp_ prefix), the DROP PROCEDURE statement will
search the current database. If it doesnt find a user-defined system stored procedure
of the same name, it will search the Master database.
To drop a group of stored procedures, specify the name of the procedure. You cannot
delete part of a grouped procedure by using DROP PROCEDURE. For example,
if you have a set of grouped procedures named GroupedProc containing
GroupedProc;1 and GroupedProc;2, you cannot drop GroupedProc;1 without also
dropping GroupedProc;2. If you need to delete part of a grouped procedure, drop
the grouped procedure and re-create it.
Before dropping a stored procedure, you should check whether other database
objects depend on the stored procedure you are dropping. Use the sp_depends system
stored procedure to check for dependent objects. You need to be concerned
only with the objects that depend on the stored procedure you intend to delete.
Tip You can create, execute, alter, and drop user-defined stored procedures in
Query Analyzer by right-clicking the stored procedure and pointing to any of the
Script Object To... options. To generate the script in Query Analyzer, click Script
Object To New Window.
Exercise 2: Working with Stored Procedures

In this exercise, you will create a stored procedure in the Northwind database and
verify that it was created. In the remaining practices for this lesson, you will execute,
alter, and drop this procedure. In Exercise 3, you will create stored procedures
for the BookShopDB database.
_
To create a stored procedure in the Northwind database

2. Close the Object Browser window if it is displayed.
Implementation
3. Expand the Query window so that it occupies all of the workspace in Query
Analyzer.
4. In the Editor pane of the Query window, enter and execute the following code:
USE northwind
GO
CREATE PROCEDURE dbo.CustOrderHistRep
@CustomerID char(5)
AS
SELECT ContactName, ContactTitle
FROM Customers WHERE CustomerID = @CustomerID
SELECT ProductName, Total=SUM(Quantity)
FROM Products P, [Order Details] OD, Orders O, Customers C
WHERE
C.CustomerID = @CustomerID AND C.CustomerID = O.CustomerID
AND O.OrderID = OD.OrderID AND OD.ProductID = P.ProductID

GROUP BY ProductName
GO
The Northwind database is made the current database in the first batch. Then, a
procedure named CustOrderHistRep is created and a single input parameter,
@CustomerID, is defined. The input parameter can appear on the same line as
the CREATE PROCEDURE line, but it appears on its own line here for clarity.
A similar approach for separating the code appears below the SELECT statements.
Notice that the data type for @CustomerID is set to char(5). If you
query the [northwind].[dbo].[customers] table, you will see that all customer
IDs are five characters long. The line that has a single keyword, AS, is the
demarcation line between the procedures creation in the SysObjects table and
the text contained in the procedure and stored in the SysComments table.
5. Review but do not spend too much time on the SELECT statements that appear
below the AS keyword.
When the query is executed, the first SELECT statement displays a persons
name and title for the customer ID entered. The second SELECT statement displays
all product names purchased by the customer and the total quantity
(SUM) of each product. The result set returns the data grouped by product
name. You might notice that multiple joins were accomplished by the WHERE
clause, rather than by the FROM clause. When the procedure is modified, you
will move the JOIN expressions to the FROM clause.
Note You should be somewhat familiar with the code in the SELECT statements.
If you need a review of the language in the SELECT statement, refer to Chapter 6,
Accessing and Modifying Data.
_
To view the stored procedure object in Query Analyzer
1. Open the Object Browser in Query Analyzer and expand the Northwind
database.
2. Expand the Stored Procedures node.
All stored procedures created for the Northwind database appear.
3. Expand the dbo.CustOrderHistRep stored procedure.
Notice that the stored procedure is owned by dbo and that two nodes appear
below dbo.CustOrderHistRep: Parameters and Dependencies.
4. Expand the Parameters node.
Notice that there are two parameters for this stored procedure: the @CustomerID
parameter that you created and the built-in return code parameter,
@RETURN_VALUE.
5. Expand the Dependencies node.
Notice that this stored procedure depends on four objects: the Orders, Products,
Order Details, and Customers tables in the Northwind database. No objects
depend on this stored procedure.
6. Switch to the Editor pane of the Query window.
7. On a blank line at the bottom of the Editor pane, enter and execute the following
line:
sp_depends custorderhistrep
The sp_depends stored procedure checks the CustOrderHistRep stored procedure

to determine dependencies.
Notice that the Name column contains duplicate entries, but that for any duplicate
entries, the row values are different.
8. Do not close Query Analyzer, because you will use it in the next practice.
_
To execute the stored procedure
1. On a blank line at the bottom of the Editor pane, enter and execute the following
code:
EXEC [northwind].[dbo].[custorderhistrep]
@CustomerID = thecr
The shortened version of the EXECUTE keyword, EXEC, is used to run the
stored procedure, CustOrderHistRep. Notice that the fully qualified name of the
procedure was specified. This specification is not necessary, but it enables you
to run the procedure without first making sure that the current database is
Northwind.
Two result sets are returned. The first result set (contact name and contact title)
appears in the upper portion of the Results pane. The second result set (product
name and product totals) appears in the bottom portion of the Results pane.
Implementation
In the previous example, EXEC was specified to run the stored procedure. Was
it necessary to use this keyword?
2. Find the dbo.CustOrderHistRep stored procedure in the Object Browser and
right-click it.
3. From the context menu, point to Script Object to New Windows As and then
click Execute.
Query Analyzer loads a new page into the Query Window editor, and the EXECUTE
statement for dbo.CustOrderHistRep appears. Notice that two variables
are declared: @RC and @CustomerID. The first variable is used to hold any
return codes that are part of the procedure, and the second variable holds the
value of the input parameter, @CustomerID. Notice that in the EXEC statement,
@RC is equal to the stored procedure. This relationship captures any
return codes from the procedure and places them into @RC. In Lesson 3, you
will learn more about declaring variables when executing a stored procedure
and setting the return code parameter equal to the stored procedure.
4. In the Editor pane, click the mouse at the end of the EXEC statement so that a
blinking cursor appears after the word @CustomerID. Append the following
line to the end of the line: = thecr. The EXEC statement should look like the
following:
EXEC @RC = [Northwind].[dbo].[CustOrderHistRep] @CustomerID = thecr
5. Execute the query.

The query returns the same result set observed previously in this practice.
6. Close the new page created in the Query window, but do not close Query Analyzer
or the original page that appears in the Editor pane.
A Query Analyzer message appears, asking you whether you want to save the
changes.
7. Click No.
The original page in the Editor pane appears.
_
To modify the stored procedure
1. In the Editor pane of the Query window, locate the following code:
USE Northwind
GO
CREATE PROCEDURE dbo.CustOrderHistRep
@CustomerID char(5)
AS
FROM Products P, [Order Details] OD, Orders O, Customers C
WHERE
C.CustomerID = @CustomerID AND C.CustomerID = O.CustomerID

AND O.OrderID = OD.OrderID AND OD.ProductID = P.ProductID
GO
2. Change the CREATE keyword to ALTER.

When the text in the procedure is changed, the ALTER keyword will enable the
stored procedure to be changed without losing any properties configured for the
object.
3. You want the order quantity to be listed in Descending order. Add the following
statement below the GROUP BY ProductName statement:
ORDER BY Total DESC
4. You have also decided to move the table joins from the WHERE clause to the
FROM clause. The final form of the code should be similar to the following:
USE Northwind
GO
ALTER PROCEDURE dbo.CustOrderHistRep
@CustomerID char(5)
AS
FROM Products P INNER JOIN [Order Details] OD
ON P.ProductID = OD.ProductID JOIN Orders O
ON OD.OrderID = O.OrderID JOIN Customers C
ON O.CustomerID = C.CustomerID
WHERE C.CustomerID = @CustomerID
ORDER BY Total DESC
GO

6. To verify that the changes were made, go to the bottom of the Editor pane, press
ENTER, then enter and execute the following statement:
sp_helptext custorderhistrep
The stored procedure text appears on the Grids tab in the Results pane.
7. Leave the Query Analyzer open for the next exercise.
_
To delete the stored procedure
1. Go to the bottom of the Editor pane, press ENTER, then enter and execute the
following statement:
DROP PROCEDURE dbo.custorderhistrep
The stored procedure is deleted from the Northwind database.

2. Use the Object Browser in Query Analyzer or Enterprise Manager to verify that
the stored procedure was removed.
Implementation
3. Close the Query Analyzer.

You are prompted to save the script.
4. If you wish to save this script, select Yes. Otherwise, press No.
Lesson Summary
The CREATE PROCEDURE keywords are used to create procedures that are
stored in a database. Procedures are created using graphical tools such as Enterprise
Manager or command-prompt tools such as osql. Upon creation, the name of
the procedure appears in SysObjects, and the procedures content is stored in
SysComments. When a procedure is created, it can be grouped, include return
codes, require input parameters, supply default values for parameters, specify output
parameters, be encrypted, or specify whether an execution plan should be created
and whether the procedure should execute on a replication subscriber. The
fundamental reason for creating a procedure is to complete a task when the procedure
is executed. The EXECUTE keyword is used to run a procedure. A procedure
can be run manually or flagged so that it starts when SQL Server starts. If a procedure
requires modification, it is more efficient to use the ALTER PROCEDURE
statement instead of deleting a procedure and recreating it. ALTER PROCEDURE
maintains most of the original stored procedure objects properties. Deleting a
stored procedure is accomplished by using the DROP PROCEDURE statement. If a
user-defined system stored procedure is not located in the current database, SQL
Server will search the Master database to delete the procedure.
Lesson 3: Programming Stored

Procedures
Stored procedures provide a powerful method for coding tasks in the Transact-SQL
language. In the previous lesson, you learned how to create, alter, drop, and execute
stored procedures. You also saw how to use an input parameter to pass a value to a
stored procedure when it executes. This lesson explores the use of both input and
output parameters and introduces variables. You will also learn how to handle
errors in your stored procedures with return codes and the @@ERROR function.
The last part of this lesson introduces you to nesting and using cursors in stored
procedures.
Use parameters, return codes, variables, and cursors in stored procedures.
Create nested stored procedures and error-handling code.
Parameters and Variables

Parameters and variables are a fundamental part of making a stored procedure
dynamic. Input parameters enable the user who is running the procedure to pass
values to the stored procedure, making the result set unique to the request. Output
parameters extend the output of your stored procedures beyond the standard result
sets returned from a query. The data from an output parameter is captured in memory
when the procedure executes. To return a value from the output parameter, you
must create a variable to hold the value. You can display the value with SELECT or
PRINT commands, or you can use the value to complete other commands in the
procedure.
You might be a bit more familiar with input parameters than with output parameters.
You used an input parameter (@CustomerID) when you created the CustOrderHistRep stored procedure in Lesson 2. Before running CustOrderHistRep,
you set the @CustomerID parameter equal to the RC, and then you executed the
procedure.
In summary, an input parameter is defined in a stored procedure, and a value is provided
to the input parameter when the procedure is executed. An output parameter
is defined in a stored procedure by using the OUTPUT keyword. When the procedure
executes, a value for the output parameter is stored in memory. To put the
value somewhere useful, you declare a variable to hold the value. Output values are
typically displayed when the procedure execution completes.
Implementation
The following procedure shows the use of both input and output parameters:
USE Pubs
GO
CREATE PROCEDURE dbo.SalesForTitle
@Title varchar(80), -- This is the input parameter.
@YtdSales int OUTPUT, -- This is the first output parameter.
@TitleText varchar(80) OUTPUT --This is the second output parameter.
AS
-- Assign the column data to the output parameters and
-- check for a title thats like the title input parameter.
SELECT @YtdSales = ytd_sales, @TitleText=title
FROM titles WHERE title LIKE @Title
GO
The input parameter is @Title, and the output parameters are @YtdSales and
@TitleText. Notice that all three parameters have defined data types. The output
parameters include the mandatory OUTPUT keyword. After the parameters are
defined, the SELECT statement uses all three parameters. First, the output parameters
are set equal to the column names in the query. When the query is run, the output
parameters will contain the values from these two columns. The WHERE
clause of the SELECT statement contains the input parameter, @Title. When the
procedure is executed, you must provide a value for this input parameter or the
query will fail. Later in this lesson, you will learn how to handle errors and provide
default values for parameters.
The following statement executes the stored procedure that you just examined:
-- Declare variables to receive output values from procedure.
DECLARE @y_YtdSales int, @t_TitleText varchar(80)
EXECUTE SalesForTitle
--set the values for output parameters to the variables.
@YtdSales = @y_YtdSales OUTPUT,
@TitleText = @t_TitleText OUTPUT,
@Title = %Garlic% --specify a value for input parameter.
-- Display the variables returned by executing the procedure.
Select Title = @t_TitleText, Number of Sales = @y_YtdSales
GO
Two variables are declared: @y_YtdSales and @t_TitleText. These two variables
will receive the values stored in the output parameters. Notice that the data types
declared for these two variables match the data types of their corresponding output
parameters. These two variables can be named the same as the output parameters
because the variables in a stored procedure are local to the batch that contains
them. For clarity, the variable names are different from the output parameters.
When the variable is declared, it is not matched with an output parameter. Variables
are matched with output parameters after the EXECUTE statement. Notice that the
OUTPUT keyword is specified when the output parameters are set as equal to the
variables. If OUTPUT is not specified, the variables cannot display values in the
SELECT statement at the bottom of this batch. Finally, notice that the input parameter
@Title is set equal to %Garlic%. This value is sent to the WHERE clause of
the stored procedures SELECT statement. Because the WHERE clause uses the
LIKE keyword, you can use wildcards such as % so that the query searches for titles
that contain the word Garlic.
A more succinct way to execute the procedure is shown next. Notice that it is not
necessary to specifically assign the variables from the stored procedure to the value
of the input parameter or the output variables declared here:
DECLARE @y_YtdSales int, @t_TitleText varchar(80)
"%Garlic%", --sets the value of the input parameter.
@y_YtdSales OUTPUT, --receives the first output parameter
@t_TitleText OUTPUT --receives the second output parameter
-- Display the variables returned by executing the procedure.
Select Title = @t_TitleText, Number of Sales = @y_YtdSales
GO
When the procedure is executed, it returns the following:

An interesting result of this procedure is that only a single row of data is returned.
Even if the SELECT statement in the procedure returns multiple rows, each variable
holds a single value (the last row of data returned). Several solutions to this
problem are explained later in this lesson.
The RETURN Statement and Error Handling

Often, the majority of coding in a well-written stored procedure (or in any program,
for that matter) involves error handling. SQL Server provides functions and
statements to deal with errors that occur during procedure execution. The two primary
categories of errors are computer errors, such as an unavailable database
server, and user errors. Return codes and the @@ERROR function are used to handle
errors that occur when a procedure is executed.
Return codes can be used for other purposes besides error handling. The RETURN
statement is used to generate return codes and exit a batch, and it can provide any
integer value to a calling program. You will see code samples in this section that
use the RETURN statement to supply a value for both error-handling and other purposes.
The RETURN statement is used primarily for error handling because when
the RETURN statement runs, the stored procedure exits unconditionally.
Title Number of Sales
Onions, Leeks, and Garlic: Cooking Secrets of the
Mediterranean
375
Implementation
Consider the SalesForTitle procedure that you created and executed in the last section.
If the value specified for the input parameter (@Title) does not exist in the
database, executing the procedure returns the following result set:
It is more instructive to explain to the user that there were no matching records.
The following example shows how to modify the SalesForTitle stored procedure to
use a RETURN code (and thus provide a more useful message):
ALTER PROCEDURE dbo.SalesForTitle
@Title varchar(80), @YtdSales int OUTPUT,
@TitleText varchar(80) OUTPUT
AS
--Check to see if the title is in the database. If it isnt,
--exit the procedure and set the return code to 1.
IF (SELECT COUNT(*) FROM titles WHERE title LIKE @Title) = 0
RETURN(1)
ELSE
GO
The IF statement below the AS keyword determines whether the input parameter is
provided when the procedure is executed and matches any records in the database.
If the COUNT function returns 0, then the return code is set to 1, RETURN(1). If
the COUNT function returns anything else, the SELECT statement queries the Title
table for annual sales and book title information. In this case, the return code is
equal to 0.
Note The initial USE Pubs statement has been removed from the script because it
isnt the focus of the sample code. If you run this code make sure that you have
switched to the Pubs database first. As you move through the code examples, you
might notice other space-saving code consolidations (such as removing code comments
and adding others). You should make a point of commenting your code so
that it is maintainable and relatively easy to understand.
Some recoding of the execution statement is necessary to use the return code. The
following example sets the input parameter @Title equal to Garlic%:
--Add @r_Code to hold the result code.
DECLARE @y_YtdSales int, @t_TitleText varchar(80), @r_Code int
--Run the procedure and set @r_Code equal to the procedure.
EXECUTE @r_Code = SalesForTitle
@TitleText = @t_TitleText OUTPUT,

NULL NULL
@Title = Garlic%"
--Determine the value of @r_Code and execute the code.
IF @r_Code = 0
SELECT Title = @t_TitleText,

"Number of Sales = @y_YtdSales, Return Code = @r_Code
ELSE IF @r_Code = 1
PRINT No matching titles in the database. Return code= + CONVERT(varch
ar(1),@r_Code)
GO
A new variable has been added to the end of the DECLARE statement: @r_Code.
Later in the code, this variable contains the value provided by the RETURN keyword.
This variable is defined as an integer data type because the return code sends
an integer value. The @r_Code variable is set to the return code on the EXECUTE
line. Notice that @r_Code is set equal to the stored procedure. The value for the
input parameter, @Title, is now Garlic% rather than %Garlic%. In other words, the
SELECT statement in the procedure will search for records in the Titles table starting
with the word Garlic. Conditional logic appears below the parameters and
comments. The first IF statement is tested. If the procedure finds a record, then the
return code is 0, and the SELECT statement runs. If the procedure doesnt find any
matching records, @r_Code will equal 1 and the PRINT statement will run.
Because there isnt a title in the database that begins with the word Garlic, executing
the procedure returns the PRINT statement:
No matching titles in the database. Return code=1
Changing the input parameter to %Garlic% and executing the code returns the following
result set:
If you dont enter a value for the @Title input parameter, the result of executing the
query is the following message:
Server: Msg 201, Level 16, State 3, Procedure SalesForTitle, Line 0
Procedure SalesForTitle expects parameter @Title, which was not supp
lied.
Default Values and Setting a Parameter to NULL

To test for a NULL value for the @Title input parameters, you must set a default
value for the input parameter and modify the stored procedure by adding another
conditional statement. Setting a default value is a powerful error-avoidance technique.
If you set @Title to a value contained in the database, the SELECT statement
would use the default for the input parameter. In this case, its more
Title
Number
of Sales
Return
Code
Onions, Leeks, and Garlic: Cooking Secrets of the

Mediterranean
375 0
Implementation
instructive to the user if you set a default of NULL for the input parameter and let a
RETURN code instruct the user on how to properly execute the procedure. Modifying
the procedure in the following way accomplishes this goal:
@Title varchar(80) = NULL, @YtdSales int OUTPUT,
AS
IF @Title IS NULL
RETURN(2)
ELSE
IF (SELECT COUNT(*) FROM titles WHERE title LIKE @Title) = 0
RETURN(1)
ELSE
GO
Notice that @Title is set to a default value of NULL. A conditional IF statement

was added right after the AS keyword. This test must occur before the SELECT
COUNT statement, however, because the SELECT COUNT statement will test true
with a value of NULL.
When you execute the procedure, you must include a test for a return code of 2, as
shown in the following example:
@TitleText = @t_TitleText OUTPUT
--No value specified for the @Title input parameter.
IF @r_Code = 0
"Number of Sales = @y_YtdSales, Return code = @r_Code
ELSE IF @r_Code = 1
ar(1),@r_Code)
ELSE IF @r_Code = 2 --test for a return code of 2.
PRINT You must add a value for @Title for this procedure to function pr
operly.
Return code= + CONVERT(varchar(1),@r_Code)
GO
Testing for Server Errors

Another important category of error to test for is database errors. The @@ERROR
function enables you to test for more than 3000 different database-related errors.
This function captures database error numbers as a procedure executes. You can
use each return number to display a message to the user explaining the reason for
the error. Common user errors that lead to database errors occur in INSERT and
UPDATE statements in which a user attempts to add data that violates the integrity
of the data (such as adding an invalid identification number). The error numbers
and their descriptions are stored in the master.dbo.sysmessages table. You can
query this table with the following SELECT statement:
SELECT error, description from master.dbo.sysmessages
If a procedure executes successfully, @@ERROR is set to 0. If an error occurs, an

error number other than 0 is returned to @@ERROR. When another Transact-SQL
statement runs in a procedure, the value of @@ERROR changes. Therefore,
@@ERROR should be stored in a variable or provide a return code after each
Transact-SQL statement completes. The following example demonstrates how to
generate a return code if there is a database error:
@Title varchar(80) = NULL, @YtdSales int OUTPUT,
AS
IF @Title IS NULL
RETURN(2)
ELSE
IF (SELECT COUNT(*) FROM dbo.titles
WHERE title LIKE @Title) = 0
RETURN(1)
ELSE
FROM dbo.titles WHERE title LIKE @Title
-- Check for SQL Server database errors.
IF @@ERROR <> 0
RETURN(3)
GO
Notice that the procedure checks for the value of @@ERROR after the SELECT
statement that returns a result set when the procedure is executed. This function is
important, because the goal of @@ERROR is to check for database errors after the
core task of the stored procedure occurs.
The following code executes the procedure and displays a generic error message if
a database error occurs:

@TitleText = @t_TitleText OUTPUT, @Title = %Garlic%"
IF @r_Code = 0
"Number of Sales = @y_YtdSales, Return code = @r_Code
ELSE
Implementation
IF @r_Code = 1
ar(1),@r_Code)
ELSE
IF @r_Code = 2
PRINT You must add a value for @Title for this procedure to function pr
operly.
Return code= + CONVERT(varchar(1),@r_Code)
ELSE
IF @r_Code = 3
PRINT There was a database error.
GO
When you create a stored procedure for a production database system, you will
become familiar with the types of errors that users will make when they execute the
procedure. With this experience and your understanding of result codes, you can
write additional error-handling conditions into your procedures.
Note For more information about result codes and using the @@ERROR function,
perform a search for RESULT and @@ERROR in SQL Server Books Online.
Nesting Procedures
Nesting stored procedures simply involves calling one stored procedure from
another. A single stored procedure can perform multiple tasks, but it is better to
create simpler, more generic stored procedures that can call other stored procedures
to complete additional tasks. For example, you might write a stored procedure
called Procedure_A that inserts data into an existing table, and you might write
another stored procedure called Procedure_B that displays data from the table.
Procedure_A could call Procedure_B after successfully inserting data into a table.
Users can still run Procedure_B to view table information without having to run
Procedure_A to insert data into the table.
Procedures can be nested together up to 32 levels deep. However, there is no limit to
how many procedures a single procedure can call. A procedure can also call itself
recursively. A procedure is called from another procedure by using the EXECUTE
statement. You will nest a procedure for the BookShopDB database in Exercise 3.
Cursors
You can use cursors in stored procedures; however, you should avoid them if you
can find a way to do the same thing by using result sets. Procedures that use result
sets are more efficient on the database and on the network, and they are typically
less complex to write than cursors. Cursors are explored in Chapter 7, but are discussed
here so that you can see how to use them in stored procedures. To learn
more about cursors, read Lesson 3 in Chapter 7 of SQL Server Books Online and
Inside Microsoft SQL Server 2000 by Microsoft Press.
Data Retrieval Methods

The stored procedure code example used throughout this lesson is limited to returning
a single row of data. For example, an input parameter value of The% will
return a single row of data, with the last title starting with The% (as shown in the
following result):
A single row appears because the result set returned by the SELECT statement is
passed to a variable capable of holding only a single value.
There are a number of solutions to this problem. The simplest solution is to eliminate
the output parameters in the SELECT statement and return a record set from
the stored procedure, as shown:
@Title varchar(80)
AS
SELECT Title = title, [Number of Sales]=ytd_sales
GO
Notice that all output parameters were removed from the stored procedure. To execute
this simple stored procedure, you can use the following sample code:
@Title = The%
When you execute this procedure, the result set is as follows:

For clarity, the return code syntax has been removed from the stored procedure;
thus, the Return Code column does not appear. All book titles starting with The%
appear in the result set.
The same data can be returned with cursors. The following stored procedure places
each row of data into a cursor output parameter and returns the row of data before
fetching the next row:
@ResultCrsr CURSOR VARYING OUTPUT, @Title varchar(80) = NULL
AS
Title Number of Sales Return Code

The Psychology of Computer Cooking NULL 0
The Busy Executives Database Guide 4095
The Gourmet Microwave 22,246
The Psychology of Computer Cooking NULL
Implementation
SET @ResultCrsr = CURSOR FOR SELECT ytd_sales, title
FROM dbo.titles WHERE title LIKE @Title
OPEN @ResultCrsr
GO
The second line of code creates an output parameter called @ResultCrsr of the data
type cursor. This output parameter will hold each record returned by the cursor.
After the AS keyword, @ResultCrsr is set equal to the cursor that will eventually
contain each record of the SELECT statement. After the SELECT statement, the
OPEN statement populates the result set into the cursor.
The following code can be used to execute this stored procedure:
DECLARE @r_ResultCrsr CURSOR
EXECUTE dbo.SalesForTitle
@ResultCrsr = @r_ResultCrsr OUTPUT, @Title = The%"
FETCH NEXT FROM @r_ResultCrsr
WHILE (@@FETCH_STATUS <> -1)
BEGIN
FETCH NEXT FROM @r_ResultCrsr
END
CLOSE @r_ResultCrsr
DEALLOCATE @r_ResultCrsr
GO
All three records from the database are returned. The output data is the same as the
result set example shown earlier in this section, except that each record appears
separately in the results pane. An additional empty row is returned because the
@@FETCH_STATUS is not set to 1 until after an empty row is retrieved.
Exercise 3: Programming Stored Procedures to Insert and

Retrieve Data
In this exercise, you will create a stored procedure to insert new customer records
into the BookShopDB database. You will then create a stored procedure that
checks for duplicate customer records in the database. The second procedure you
create will be nested in the first procedure. The stored procedures will include
parameters, variables, return codes, the @@ERROR function, and control of flow
language.
_
To create an insert customer stored procedure

USE BookShopDB
GO
CREATE PROCEDURE dbo.AddCustomer
--CustomerID not included as an input parameter because

--the ID is automatically generated (Identity column)
@FirstName varchar(30), @LastName varchar(30),
@Phone varchar(24), @Address1 varchar(60),
@Address2 varchar(60) = unknown, @City varchar(15),
@State varchar(7), @Zip varchar(12)
AS
INSERT [BookShopDB].[dbo].[Customers]
(FirstName, LastName, Phone, Address1,
Address2, City, State, Zip)
VALUES
(@FirstName, @LastName, @Phone, @Address1,
@Address2, @City, @State, @Zip)
RETURN(SELECT @@IDENTITY AS Identity)
GO
In this statement, you create a stored procedure named AddCustomer. You specify
all of the required input parameters. Notice that a default value of unknown
is provided for Address2. Address2 isnt always part of a customers address.
The value of unknown matches the default value of the check constraint
applied to this column. At the end of the code, the RETURN statement contains
the customer ID value, which is retrieved by the @@IDENTITY function.
DECLARE @r_Code int
EXECUTE @r_Code=dbo.AddCustomer
@FirstName = Jamie, @LastName = Marra,
@Phone = 425-555-1212, @Address1 = 20 Oak St., SE,
@City = Remy, @State = WA, @Zip = 98888
SELECT [Customer ID] = The new customer ID is: + CONVERT(CHAR(2), @
r_Code)
The code creates a variable of type integer named @r_Code. This variable is set
equal to the stored procedure name upon execution. Lesson 3s code examples
showed an example of using a return code for error handling. In this procedure,
the return code will contain the value of the @@IDENTITY function when the
stored procedure executes.
_
To add error-handling techniques to the stored procedure
1. The AddCustomer stored procedure does not contain any error handling. The
procedure needs to be modified to include error-handling logic. In the Editor
pane of the Query window, enter and execute the following code:
ALTER PROCEDURE dbo.AddCustomer
@FirstName varchar(30)= unknown,
@LastName varchar(30)= unknown, @Phone varchar(24) = NULL,
@Address1 varchar(60) = NULL,
@Address2 varchar(60) = unknown, @City varchar(15) = NULL,
@State varchar(7) = NULL, @Zip varchar(12) = NULL
AS
IF (@FirstName = unknown) AND (@LastName = unknown)
Implementation
RETURN(1)
ELSE IF @Phone IS NULL
RETURN(2)
ELSE IF
@Address1 IS NULL OR @City IS NULL OR
@State IS NULL OR @Zip IS NULL
RETURN(3)
ELSE
(FirstName, LastName, Phone, Address1,
Address2, City, State, Zip)
VALUES
(@FirstName, @LastName, @Phone, @Address1,
@Address2, @City, @State, @Zip)
IF @@ERROR <> 0
RETURN(4)
GO
All input variables now contain default values. This method is an important
error-avoidance technique. For example, if no value is specified for @FirstName, it will default to unknown and the procedure will execute properly. If
the user doesnt enter a first name or a last name for the customer, however, the
procedure returns a value of 1. This part of the code complies with the business
rule that a first name or a last name is required, and it matches with the check
constraint applied to the FirstName and LastName columns of BookShopDB. If
no phone number is entered, the default value of NULL is used, and a return
code of 2 is sent to the executing procedure. If any address information is missing,
a return code of 3 is sent to the executing procedure. Notice that the
@Address2 input parameter is not part of address error checking because it is
not always required. If all input parameters are specified, the INSERT statement
is called. If the INSERT statement fails because of a database error, a return
code of 4 is sent to the executing program.
As you work with the stored procedure, you will want to add additional error
handling to the code. For example, you should check the database for duplicate
customer information before creating a new customer record.
Comments were left out of the code to save space. Make sure that any code you
write is fully commented inline so that others will understand the purpose of
your code (and to help you remember the purpose of your code). Add comments
to the beginning of your code to summarize the purpose of the procedure,
the creation date, and your name or initials.
DECLARE @r_Code int
@FirstName= Jamie, @LastName = Marra,

IF @r_Code = 4
BEGIN
PRINT A database error has occured.
Please contact the help desk for assistance.
END
IF @r_Code = 1
PRINT You must specify a value for the firstname or lastname
ELSE IF @r_Code = 2
PRINT You must specify a value for the phone number
ELSE IF @r_Code = 3
PRINT You must provide all address information, Street address, City
, State and Zipcode
ELSE IF @r_Code = @@IDENTITY
SELECT [Customer ID] = The new customer ID is: + CONVERT(CHAR(2),
@r_Code)
A new customer record is added to the database. Error-checking code appears
throughout the execution code. Examine each @r_Code value and the information
returned to the user in the event of an error.
Notice that the same customer information was entered as in the previous procedure
execution. In the next exercise, you will create a stored procedure to
check the Customers table to avoid creating duplicate customer information.
_
To create a stored procedure to protect against customer record duplication
1. Checking for duplicate record information is an important part of record entry.

Without this check, it is inevitable that tables will contain duplicate entries. In
the Editor pane of the Query window, enter and execute the following code:
CREATE PROCEDURE dbo.CheckForDuplicateCustomer
@1_FirstName varchar(30)= unknown,
@1_LastName varchar(30)= unknown,
@1_City varchar(15) = NULL, @1_State varchar(7) = NULL,
@1_Phone varchar(24) = NULL, @o_FirstName varchar(30) OUTPUT,
@o_LastName varchar(30) OUTPUT, @o_City varchar(15) OUTPUT,
@o_State varchar(7) OUTPUT, @o_Phone varchar(24) OUTPUT
AS
SELECT @o_FirstName=firstname, @o_LastName=lastname,
@o_City=city, @o_State=state, @o_Phone=phone
FROM customers
WHERE firstname=@1_FirstName AND lastname=@1_LastName
AND city=@1_City AND state=@1_State AND phone=@1_Phone
IF @@ROWCOUNT <> 0
RETURN(5)
This stored procedure checks the Customers table to determine whether there is
a record with the same first name, last name, city, or phone number as the input
parameters specified. The input parameters begin with 1 to distinguish them
from the input parameters in the AddCustomer stored procedure. The output
parameters are set equal to the corresponding Customers table columns in the
Implementation
SELECT statement. A test for a record match is made in the WHERE clause.
The column values are tested against the input parameters. If the @@ROWCOUNT
function returns a value greater than 0, then a return code of 5 is set for
the stored procedure.
ALTER PROCEDURE dbo.AddCustomer
@FirstName varchar(30)= unknown,
@LastName varchar(30)= unknown, @Phone varchar(24) = NULL,
@Address1 varchar(60) = NULL,
@Address2 varchar(60) = unknown, @City varchar(15) = NULL,

@State varchar(7) = NULL, @Zip varchar(12) = NULL
AS
IF (@FirstName = unknown) AND (@LastName = unknown)
RETURN(1)
ELSE IF @Phone IS NULL
RETURN(2)
ELSE IF @Address1 IS NULL OR @City IS NULL
OR @State IS NULL OR @Zip IS NULL
RETURN(3)
--begin nesting
DECLARE @r_Code int, @v_FirstName varchar(30),
@v_LastName varchar(30), @v_City varchar(15),
@v_State varchar(7), @v_Phone varchar(24)
EXECUTE @r_Code=dbo.CheckForDuplicateCustomer
@1_FirstName = @FirstName, @1_LastName = @LastName,
@1_City = @City, @1_State = @State, @1_Phone = @Phone,
@o_FirstName = @v_FirstName OUTPUT,
@o_LastName = @v_LastName OUTPUT, @o_City = @v_City OUTPUT,
@o_State = @v_State OUTPUT, @o_Phone = @v_Phone OUTPUT
IF @@ROWCOUNT > 0
BEGIN
PRINT A duplicate record was found for + @v_FirstName + + @v
_LastName
PRINT in + @v_City + + @v_State + with a phone number
PRINT of + @v_Phone + .
RETURN(5)
END
--end nesting
(FirstName, LastName, Phone,
Address1, Address2, City, State, Zip)
VALUES
(@FirstName, @LastName, @Phone,
@Address1, @Address2, @City, @State, @Zip)
IF @@ERROR <> 0
RETURN(4)
GO
The CheckForDuplicateCustomer stored procedure is nested into the AddCustomer

stored procedure. The point at which nesting begins and ends has been
commented in the code. Variables beginning with v_ are created to hold the output
parameter values. Each input parameter beginning with 1_ is set equal to
the corresponding input parameter supplied when the AddCustomer stored procedure
executes. The output parameters from the CheckForDuplicateCustomer

stored procedure are then set equal to their corresponding output variables
beginning with v_. The variable values are used in the sequence of PRINT statements
that are called if the @@ROWCOUNT returns anything greater than 0.
_
To test the stored procedures
DECLARE @r_Code int
@FirstName= Jamie, @LastName = Marra,
IF @r_Code = 4
BEGIN
PRINT A database error has occured.
Please contact the help desk for assistance.
END
IF @r_Code = 1
PRINT You must specify a value for the firstname or lastname
ELSE IF @r_Code = 2
PRINT You must specify a value for the phone number
ELSE IF @r_Code = 3
PRINT You must provide all address information, Street address, City
, State and Zipcode
ELSE IF @r_Code = @@IDENTITY
SELECT [Customer ID] = The new customer ID is: + CONVERT(CHAR(2),
@r_Code)
The stored procedure returns a message stating that the record already exists.
2. Change the value of @FirstName to Jeff and @LastName to Fellinge, then execute
the query again.
The stored procedure returns a message with the new customer ID.
Lesson Summary
Important programming features available to stored procedures include parameters,
variables, return codes, functions, default values, nesting, and cursors. Input
parameters pass data to a stored procedure upon execution. Output parameters
receive data from the stored procedure. Variables are used to hold values from output
parameters. You specify an output parameter by using the OUTPUT keyword.
Implementation
You specify a variable by using the DECLARE keyword. Return codes are primarily
used for error handling. Return codes are supplied by using the RETURN keyword,
followed by an integer. When the RETURN statement is called, the stored

procedure code exits unconditionally. If an integer is supplied in the RETURN
statement, it is sent to a variable when the procedure is executed. The variable is set
as equal to the stored procedure. Then, conditional programming language is used
to match the return code with a task in the program. The @@ERROR function is
combined with return codes in the stored procedure to capture database errors.
Some errors can be avoided by setting default values for parameters.
You should write stored procedures to complete a single task. You can then execute
one procedure from another procedure. Executing one procedure from another is
called nesting. A stored procedure that calls itself is known as recursion. Procedures
can be nested up to 32 levels deep. A powerful feature of SQL Server 2000 is
returning records from the database via cursors. Cursors can be created in a stored
procedure and called from an executing program. You should use cursors only
when absolutely necessary, because if they are misused, they can severely impact
database and network performance.
Review
The following questions are intended to reinforce key information presented in this
chapter. If you are unable to answer a question, review the appropriate lesson and
then try the question again. You can find answers to the questions in the Appendix,
Questions and Answers.
1. You create a local temporary stored procedure and ask a colleague to execute
the stored procedure. Your colleague claims that she cannot execute the stored
procedure. Why cant she execute the stored procedure?
2. Why do complex stored procedures typically execute faster the second time
they are run than the first time?
3. What security features are available for stored procedures?
4. What function can you use to check the properties of a stored procedure and
other objects in SQL Server?
5. Why is it more efficient to modify a stored procedure by using the ALTER
PROCEDURE keywords than it is to drop and re-create a stored procedure?
6. You set the current database to Northwind, and then you create a stored procedure
named #Procedure01. You then check the Northwind database for the
stored procedure, but it doesnt appear. You can run the stored procedure using
Northwind as the current database. Why are you able to execute this stored procedure
but it doesnt appear in the Northwind database?
7. In what three ways is the RETURN statement used in a stored procedure?
311
Implementing Triggers
About This Chapter
Triggers are a special class of stored procedure defined to execute automatically in
place of or after data modification. The three commands that fire a trigger are
UPDATE, INSERT, and DELETE. Use triggers to extend data integrity and to
implement complex business logic. In this chapter, you will learn when it is appropriate
to implement triggers and when basic constraints will suffice. Create triggers
by using Transact-SQL language or SQL Enterprise Manager. Management tasks
include altering, renaming, viewing, dropping, and disabling triggers. Triggers use
two pseudo tables, Inserted and Deleted, to detect data modifications. Programming
triggers requires a thorough understanding of these pseudo tables and the
Transact-SQL language. In this chapter, you will learn how to program triggers and
how to use a number of system commands and functions commonly used in trigger
programming. Tasks commonly completed by implementing triggers include maintaining
running totals and other computed values, creating an audit record of data
modifications, invoking external actions, and implementing complex data integrity.
Implementation
Before You Begin

Server computer.
Chapter 4, Implementing SQL Server Databases and Tables, Chapter 5, Implementing

Data Integrity, and in Chapter 7, Managing and Manipulating Data.
Chapter 9 Implementing Triggers 313
Lesson 1: Introduction to Triggers

Implementing data integrity features is critical for maintaining the accuracy and
consistency of the database. Complex procedural data integrity methods and business
logic can be added to a database using triggers, a special type of stored procedure
that is applied to tables and views. Data modification events cause triggers to
fire automatically. In this lesson, you will learn when to use triggers and when to
apply other less resource-intensive data integrity measures, such as cascading referential
integrity. You will also learn about the various types and classes of triggers
and their features and limitations.
Explain how to use trigger types (INSERT, UPDATE, and DELETE triggers)
and trigger classes (INSTEAD OF and AFTER triggers) to extend data integrity.
Apply cascading referential integrity in place of triggers.
Describe trigger features and limitations.
Extending Data Integrity with Triggers

The quality of a database is measured partly by the consistency and accuracy of the
data in the database. Declarative data integrity and procedural data integrity are
used to maintain data consistency and accuracy. Chapter 5, Implementing Data
Integrity, explored declarative data integrity methods. This chapter explores a
common procedural data integrity method, triggers.
Triggers enable you to write a procedure that is invoked when table data is modified
with an INSERT, UPDATE, or DELETE action. A trigger is applied to either a
table or a view. Triggers are used to enforce business rules in the database. For
example, one business rule identified for the BookShopDB database is as follows:
When a book is added to an order, it is marked as sold in the inventory. A trigger
applied to the BookOrders table can fire when a book order is inserted. The business
logic in the trigger locates the book in the Books table and flags the book as
sold. You will create this trigger in Exercise 3.
Procedural Data Integrity

Before choosing to implement a trigger, consider whether the same results can be
achieved by using constraints or rules. Use entity integrity to uniquely identify rows
of table data (primary key and unique key constraints). Use domain integrity to
define default values (default constraints) and to restrict column data to acceptable
values (check and referential constraints). Use referential integrity to enforce logical
relationships between tables (foreign key and check constraints). Use default
Implementation
constraints to provide a value for a required field when the field is not specified in
an INSERT statement. Use constraints before choosing to use triggers and rules.
Rules remain in SQL Server 2000 for backward compatibility, and the overuse of
triggers can degrade system performance. The query optimizer uses constraint definitions
to build high-performance query-execution plans. Chapter 5 discusses all
data integrity methods (except for triggers). Triggers are especially useful because
they can contain significantly more complex processing logic than is possible with
declarative integrity methods. Use triggers in the following instances:
If using declarative data integrity methods does not meet the functional needs
of the application. For example, create a trigger that changes a numeric value in
a table when a record in the same table is removed.
Changes must cascade through related tables in the database. For example, create
and apply a trigger to an Orders table so that when an order is placed, stock
quantity in an inventory table is changed. Create and apply another trigger to
the Inventory table so that when the quantity changes, a purchase request is
added to the Purchasing table.
Use cascading referential integrity constraints instead of a custom trigger if
your goal is to update or delete a foreign key constraint.
If the database is denormalized and requires an automated way to update redundant
data contained in multiple tables.
If a value in one table must be validated against a non-identical value in another
table.
If customized messages and complex error handling are required.
Trigger Features and Limitations

Cascading referential integrity extends the accuracy and consistency of data by
applying updates or deletions to foreign keys within the database. Triggers go further
by extending data integrity to any table column in the database or even to
objects outside the current database. You can also apply triggers to views.
A single trigger can run multiple actions, and it can be fired by more than one
event. For example, you can create a single trigger that runs when any valid event,
INSERT, UPDATE, or DELETE occurs. Within the Transact-SQL code, you can
define business logic to handle each type of event.
Triggers cannot be created on a temporary or system table, although the TransactSQL language within the trigger can reference temporary tables or system tables.
An important limitation to be aware of is that INSTEAD OF DELETE and
INSTEAD OF UPDATE triggers cannot be defined on tables that have corresponding
ON DELETE or ON UPDATE cascading referential integrity defined. You will
learn more about INSTEAD OF triggers later in this lesson.
Trigger Events
Three events automatically fire a trigger: INSERT, UPDATE, and DELETE events
that occur on a table or on a view. Triggers cannot be fired manually. The trigger
syntax always includes defining one or more of these events before the taskspecific
Transact-SQL language is specified. Trigger types correspond to the event.
For example, you can create an update trigger so that when an update occurs to a
table, the update trigger is fired. A single trigger can be assigned multiple events so
that you could have a procedure that is both an update and an insert trigger. The
events can be listed in any order within the trigger definition. You will learn more
about trigger syntax in Lesson 2.
There are certain instances when an event that modifies or deletes data does not fire
a corresponding trigger. For example, the TRUNCATE TABLE statement does not
fire triggers defined for DELETE events. An important feature of triggers is that
unsuccessful transactions are automatically rolled back. Because TRUNCATE
TABLE is not a logged event, it cannot be rolled back so it doesnt fire the DELETE
trigger. Additionally, the WRITETEXT statement does not cause the INSERT or
UPDATE triggers to fire.
Trigger Execution
When a table insert or update fires a trigger, the trigger stores the new or modified
data in a table named Inserted. When a table delete fires a trigger, the trigger stores
the deleted data in a table named Deleted. The table exists in memory and is queried
within the trigger by using Transact-SQL commands. This capability is critical
to the function of most triggers because the task within the trigger, such as modifying
a value in an associated table, compares the data contained in the Inserted or
Deleted tables to the data in the modified table before the changes are committed.
By using the information stored in the Inserted or Deleted table, a trigger can roll
back a transaction to enforce business rules.

There are two classes of triggers in SQL Server 2000: INSTEAD OF and AFTER.
INSTEAD OF triggers bypass the triggering action and run in their place. For
example, an update to a table containing an INSTEAD OF trigger will run the trigger
Transact-SQL code rather than the update statement. This feature enables you
to specify complex processing statements within the trigger to augment the tablemodification
statement. AFTER triggers fire as a supplement to the triggering
action and are the default trigger class. A trigger can be applied to only a single
table or view.
Implementation
There are a number of important differences between these trigger classes, as

shown in the following table:
You can apply both classes of triggers to a table. If you have defined both trigger
classes and constraints for a table, the INSTEAD OF trigger fires. Then, constraints
are processed and AFTER triggers fire. If constraints are violated, INSTEAD OF
trigger actions are rolled back. AFTER triggers do not execute if constraints are
violated or if some other event causes the table modification to fail.
Like stored procedures, triggers can be nested up to 32 levels deep and can be fired
recursively. For more information about trigger nesting and recursion, search the
Transact-SQL Reference in SQL Server Books Online for a page titled CREATE
TRIGGER.
Exercise 1: Applying Cascading Referential Integrity

Constraints
In this exercise, you will add cascading referential integrity constraints to the
BookShopDB database. This new SQL Server 2000 feature takes the place of a
common trigger task, performing cascading deletes and updates to foreign keys.
_
To configure cascading referential integrity on BookShopDB for the TitleID
key
Characteristic INSTEAD OF AFTER
Applied to Defined on a table or a view. Defined on a table.
Defining a trigger on a view
extends the types of updates that
a view can support.
Modifications to views will fire

AFTER triggers when table data
is modified in response to the
view modification.
Number allowed Only one per triggering action is
allowed on a table or view.
More than one allowed on a table.
You can define views of other
views where each view has its
own INSTEAD OF trigger.
Order of execution Only one per triggering action is
allowed on a table or view, so the
order is irrelevant.
Can define which trigger fires first
and last.
Use the sp_settriggerorder system
stored procedure to define the first
and last trigger. All other triggers
applied to a table execute in random
order.
USE BookShopDB
INSERT Orders (CustomerID, EmployeeID, Amount, OrderDate, DeliveryDat
e, PaymentID, StatusID)
VALUES (10, 1, 30, GetDate(), DATEADD(day, 5, GetDate()), 1, 1)
INSERT BookOrders (titleid, orderid) VALUES (aust1234, 3)
The first INSERT statement adds an order to the Orders table. The OrderDate
and DeliveryDate values are provided by functions. The first function returns
todays date (as specified by your computer). The second function adds five
days onto the value returned by GetDate. The second INSERT statement adds a
record to the BookOrders table. These two insert statements are important for
testing the effect of enabling cascading referential integrity for the TitleID foreign
key in the BookOrders table.
3. In the Editor pane of the Query window, enter and execute the following
Transact-SQL code:
UPDATE Books
SET TitleID = AUST1235
WHERE TitleID = AUST1234
The following error message appears in the Message tab of the Results pane:
Server: Msg 547, Level 16, State 1, Line 1
UPDATE statement conflicted with COLUMN REFERENCE constraint titleid
_fk. The conflict occurred in database BookShopDB, table BookAuth
ors, column TitleID.
The statement has been terminated.
This error message is caused because the foreign key constraint, titleid_fk, is
violated by attempting to change the TitleID primary key value in the Books
table.
Transact-SQL code:
ALTER TABLE BookAuthors DROP CONSTRAINT titleid_fk
This ALTER TABLE statement removes the titleid_fk foreign key constraint
from the BookAuthors table.
code:
ALTER TABLE BookAuthors
ADD CONSTRAINT titleid_fk FOREIGN KEY (TitleID) REFERENCES Books (Tit
leID)
ON UPDATE CASCADE ON DELETE CASCADE
This ALTER TABLE statement adds cascading referential integrity to the foreign
key constraint (titleid_fk) in the BookAuthors table. When an update to the
TitleID primary key occurs in the Books table, the corresponding foreign key
will be changed in the BookOrders table. The titleid_fk foreign key constraint
makes the Books table the parent of the BookAuthors table.
Implementation
6. Execute the Transact-SQL code.

Transact-SQL code:
UPDATE Books
An error message appears because the foreign key constraint, titleid2_fk,

applied to the BookOrders table, was violated by attempting to change the
TitleID primary key value in the Books table.
Transact-SQL code:
ALTER TABLE BookOrders DROP CONSTRAINT titleid2_fk
ALTER TABLE BookOrders

ADD CONSTRAINT titleid2_fk FOREIGN KEY (TitleID) REFERENCES Books (Ti
tleID)
ON UPDATE CASCADE ON DELETE CASCADE
The first ALTER TABLE statement drops the titleid2_fk constraint from the
BookOrders table. The second ALTER TABLE statement adds cascading referential
integrity to the titleid2_fk foreign key constraint. The titleid2_fk foreign
key constraint makes the Books table the parent of the BookOrders table.
Transact-SQL code:
UPDATE Books
The TitleID is updated in the Books table, and because of cascading referential
integrity, it is also updated in the BookAuthors and BookOrders tables.
Transact-SQL code:
SELECT Books TitleID = b.titleID, BookAuthors TitleID
= ba.titleID,
"BookOrders TitleID = bo.titleID
FROM books b INNER JOIN bookauthors ba ON b.titleID=ba.titleID
INNER JOIN bookorders bo ON b.titleID=bo.titleID
WHERE b.titleid=aust1235
The Grids tab of the Results pane shows that the TitleID column has been
updated in all three tables.
Transact-SQL code:
DELETE FROM Books where TitleID = AUST1235
Because of cascading referential integrity being defined for deletions, the

DELETE statement removes the record from the Books, BookOrders, and
BookAuthors tables. You can verify this fact by running the SELECT statement
that appears in step 10.
Transact-SQL code:
ALTER TABLE BookAuthors DROP CONSTRAINT titleid_fk
ALTER TABLE BookOrders DROP CONSTRAINT titleid2_fk
ALTER TABLE BookAuthors
ADD CONSTRAINT titleid_fk FOREIGN KEY (TitleID) REFERENCES Books (T
itleID)
ALTER TABLE BookOrders

ADD CONSTRAINT titleid2_fk FOREIGN KEY (TitleID) REFERENCES Books (
TitleID)
INSERT Books (TitleID, Title, Publisher, PubDate, Edition, Cost, SRP,
ConditionID, Sold)
VALUES (AUST1234, Sense and Sensibility, N/
A, 1811, 1, 3000, 5900, 3,0)
GO
These statements return the database to its previous state.
Lesson Summary
Procedural data integrity is often implemented by using triggers. Triggers are
invoked when table data is modified by an INSERT, UPDATE, or DELETE event.
Depending on the trigger class, a trigger can be applied to a table or view. Triggers
extend data integrity by enforcing complex business rules in the database. Always
implement constraints and rules before using triggers, because triggers will
degrade performance more quickly than constraints or rules. There are certain
instances in which a trigger is the best option (for example, when custom error
messages are required). Triggers can reference data inside or outside the current
database. A single trigger can run multiple tasks and can be fired by more than one
event. You cannot create a trigger on a temporary or system table, but these objects
can be referenced in a trigger. Some events, such as a truncate table event, do not
cause a DELETE trigger to fire. Triggers use Inserted and Deleted pseudo tables to
store modified or deleted data. These pseudo tables are referenced in the trigger
code. There are two classes of triggers: INSTEAD OF and AFTER. INSTEAD OF
triggers bypass the view or table modification that fired them and the code in the
trigger runs. AFTER triggers fire right after table constraints are processed. If the
INSERT, UPDATE, or DELETE event does not complete properly, the trigger rolls
back the transaction.
Implementation
Lesson 2: Creating and Managing

Triggers
In this lesson, you will learn a number of methods for creating and managing triggers.
Triggers are commonly created and managed by using Query Analyzer or the
Manage Triggers option in Enterprise Manager. A trigger is created by using the
CREATE TRIGGER statement. In the trigger creation process, the trigger is applied
to a table or a view. After a trigger is created, it is modified by using the ALTER
TRIGGER statement. Triggers are renamed and viewed by using system stored procedures
or Enterprise Manager. The DROP TRIGGER statement is used to delete a
trigger, and the ALTER TABLE statement is used to enable or disable triggers.
Create triggers.
Rename triggers and modify their contents.
View, drop, and disable triggers.
Creating Triggers Using Transact-SQL

You can use the CREATE TRIGGER statement to create a trigger by using Query
Analyzer or a command-prompt tool such as osql. When using CREATE TRIGGER,
you must specify the trigger name, the table or view upon which the trigger is
applied, the class of trigger (INSTEAD OF or AFTER), the event or events that fire
the trigger, and the task that you wish the trigger to perform. Optionally, you can
specify whether the trigger should be replicated or encrypted. The WITH APPEND
clause remains for backward compatibility but shouldnt be used to create triggers
for a SQL Server 2000 database.
The main clauses in a CREATE TRIGGER statement can be summarized as follows:
CREATE TABLE trigger_name
ON table_name or view_name
FOR trigger_class and trigger_type(s)
AS Transact-SQL statements
This section discusses the CREATE TABLE, ON, and FOR/AFTER/INSTEAD
OF clauses in detail and provides examples of how they are used in a trigger statement.
Lesson 3 discusses the Transact-SQL statements appearing after the AS
clause. For more details about trigger clauses not shown here, refer to SQL Server
Books Online.
The CREATE TRIGGER Clause

Trigger creation begins with the CREATE TRIGGER clause followed by a trigger
name. Triggers do not allow specifying the database name as a prefix to the object
name. Therefore, select the database with the USE database_name clause and the
GO keyword before creating a trigger. GO is specified because CREATE TRIGGER
must be the first statement in a query batch.

Permission to create triggers defaults to the table owner. For consistency, consider
creating tables, triggers, and other database objects so that dbo is the owner. For
example, to create a trigger named Alerter in the BookShopDB database, you can
use the following Transact-SQL code:
USE BookShopDB
GO
CREATE TRIGGER dbo.alerter
Trigger names must follow the rules for identifiers. For example, if you decide to
create a trigger named Alerter for the Employees Table, you must enclose the name
in brackets as shown:
CREATE TRIGGER dbo.[alerter for employees table]
Administering the trigger object, such as deleting it, also requires that you follow
the rules for identifiers.
The ON Clause
Triggers must be assigned to a table or view. Use the ON clause to instruct the trigger
on to what table or view it should be applied. When a trigger is applied, the
table or view is referred to as the trigger table or the trigger view. For consistency,
specify the table or view owner after the ON clause. For example, to apply a trigger
to the Employees table named Alerter (where both objectsthe table and the trigger
are owned by dbo), you can use the following Transact-SQL code:
ON dbo.employees
A trigger is applied only to a single table or view. If you need to apply the same
trigger task to another table in the database, create a trigger of a different name that
contains the same business logic. Then, apply the new trigger to the other table.
The default trigger class, AFTER, can be applied only to a table. The new trigger
class, INSTEAD OF, can be applied to either a table or a view.
The FOR, AFTER, and INSTEAD OF Clauses

A trigger event type must be specified when the trigger is created. Valid event
types include INSERT, UPDATE, and DELETE. A single trigger can be fired
because of one, two, or all three of the events occurring. If you want a trigger to
Implementation
fire on all events, follow the FOR, AFTER, or INSTEAD OF clause with INSERT,
UPDATE, and DELETE. The event types can be listed in any order. For example,
to make the trigger named Alerter fire on all events, you can use the following
Transact-SQL code:
ON dbo.employees
FOR INSERT, UPDATE, DELETE
The FOR clause is synonymous with the AFTER clause. Therefore, the previous
code example creates an AFTER trigger. To create Alerter as an INSTEAD OF
trigger, you can use the following Transact-SQL code:
ON dbo.employees
INSTEAD OF INSERT, UPDATE, DELETE
Notice that the FOR clause is replaced with INSTEAD OF.
The AS Clause
The AS clause and the Transact-SQL language following it designates the task that
the trigger will perform. The following example shows how to create an Alerter
trigger that sends an e-mail to a user named BarryT when an INSERT, UPDATE, or
DELETE occurs on the employees table:
USE BookShopDB
GO
ON dbo.employees
AFTER INSERT, UPDATE, DELETE
AS
EXEC master..xp_sendmail BarryT,
A record was just inserted, updated or deleted in the Employees table.
GO
This example is kept simple so that you can see clearly how a task is created in a
trigger. There are a number of ways to make the task more useful. For example,
you could write the task so that the e-mail message details the exact change that
occurred. Lesson 3 explores more complex trigger tasks.
Creating a Trigger Using Enterprise Manager

You can create triggers by using the SQL-DMO interface or by using applications
such as Enterprise Manager. To create a trigger in Enterprise Manager, you must
first select the database. Next, right-click the table or view to which the trigger is
applied, point to All Tasks, and then click Manage Triggers. In the text box of the
Trigger Properties dialog box, enter the trigger statement. Figure 9.1 shows the
Trigger Properties dialog box containing the code from the previous example.
F09BQ01.eps
Figure 9.1. The General tab of the Trigger Properties dialog box for a new trigger.
Trigger Management
Triggers are powerful database objects that run automatically when a table or view
is modified. There are a number of database tools and commands used to manage
triggers. Triggers can be:
Modified by using the ALTER TRIGGER statement.
Renamed with the sp_rename system stored procedure.
Viewed by querying system tables or by using the sp_helptrigger and
sp_helptext system stored procedures.
Deleted by using the DROP TRIGGER statement.
Disabled or enabled by using the DISABLE TRIGGER and ENABLE TRIGGER
clauses of the ALTER TABLE statement.

You can also use the Manage Triggers option in Enterprise Manager to modify,
view, and delete triggers. The remainder of this lesson provides details about how
to perform these management tasks.
Altering and Renaming Triggers

To modify the text in a trigger, you can delete and recreate it. Alternatively, to skip
the deletion step, use the ALTER TRIGGER statement. The ALTER TRIGGER
statement syntax is similar to the CREATE TRIGGER statement syntax, but ALTER
TRIGGER does not remove the trigger from the SysComments and SysObjects
Implementation
system tables. The following example shows how you can modify the Alerter trigger
so that it only reports updates to the Employees table:
ALTER TRIGGER dbo.alerter
ON dbo.employees
AFTER UPDATE
AS
EXEC master..xp_sendmail BarryT,
A record was just updated in the Employees table.
GO
Notice that UPDATE is the only event specified following the AFTER clause, and
notice that the text in the e-mail message was changed.
Triggers are modified in Enterprise Manager from the Manage Triggers option.
You learned about the Manage Triggers option in the previous section of this lesson.
After you display the Trigger Properties dialog box, select the trigger that you
wish to modify. Then, change the word CREATE to ALTER. Figure 9.2 shows how
to alter the Alerter trigger using Enterprise Manager.

F09BQ02.eps
Figure 9.2. The General tab of the Trigger Properties dialog box with the ALTER syntax
shown.
Notice that the GO batch command has been removed. In the first released version
of SQL Server 2000, the GO batch command causes an error in Enterprise Manager
when attempting to modify a trigger.
There might be times that you need to rename a trigger to comply with new naming
conventions or because you are implementing more than one trigger on a table. You
can rename a trigger by using the sp_rename system stored procedure. The following
example shows how to rename the Alerter trigger to EmpAlerter:
sp_rename @objname = alerter, @newname = empalerter
Notice that dbo was not specified in the rename syntax. Trigger ownership cannot
be transferred by using the sp_rename system stored procedure. If you need to
change the ownership of a stored procedure, you must use CREATE TRIGGER. If
you are nesting a trigger that you rename, make sure that the calling trigger is modified
to call the correct trigger name.
Viewing, Dropping, and Disabling Triggers

When a stored procedure is created, its name and other identifying information are
stored in the SysObjects system table of the current database. The trigger text is
stored in the SysComments system table. The following SELECT statement will
show any triggers applied to tables in the BookShopDB database:
select * from bookshopdb..SysObjects where type = tr
The type column always lists triggers with a value of tr.

Use the sp_helptrigger system stored procedure to show the properties of a trigger.
For example, to show the properties of all triggers defined for the Employees table,
type the following:
sp_helptrigger @tabname = employees
You can query the Text column of the SysComments system table to see the contents
of the stored procedure. For a more organized display of information, use the
sp_helptext system stored procedure. For example, to show the text contained in a
trigger named alerter, type the following:
sp_helptext @objname = alerter
You can also use the Manage Triggers option of Enterprise Manager to view trigger
text.
Deleting a trigger removes it from the SysComments and SysObjects system
tables. Use the DROP TRIGGER statement to delete one or more triggers from a
database. If you drop a trigger table or a trigger view, any triggers assigned to the
table or view are also dropped. To delete the Alerter trigger in the BookShopDB
database, type the following:
USE BookShopDB
DROP TRIGGER [dbo].[alerter]
As with the CREATE TRIGGER statement, you cannot specify the database name in
the DROP TRIGGER statement. Unlike CREATE TRIGGER, DROP TRIGGER does
not have to be the first statement in the batch. For this reason, the code example does
not include a GO command between the USE and DROP TRIGGER statements.
Implementation
You might have to disable a trigger (or triggers) on a table if, for example, you are
troubleshooting a problem with a database, testing a database modification, or
running a procedure that requires a trigger to be disabled on a table. To disable a
trigger, use the ALTER TABLE statement. The following code disables the Alerter
trigger on the Employees table:
ALTER TABLE employees DISABLE TRIGGER alerter
To disable all triggers on a table, use the ALL keyword following the DISABLE
TRIGGER clause. To enable one or all triggers, change DISABLE to ENABLE in
your ALTER TABLE statement.
Exercise 2: Creating and Managing Triggers

In this exercise, you create and test a trigger that displays a message indicating that
the trigger fired. You will then manage the trigger by renaming it, modifying its
contents, viewing it, disabling it, and then dropping it from the database. The
Transact-SQL code appearing below the AS clause is intentionally simplistic,
because Lesson 3 explores this aspect of triggers.
Note For the purpose of this exercise, its fine to display a message when a trigger
fires. However, you should design triggers for your databases that do not display
result sets and that do not print messages to the screen.
_
To create simple triggers on the Authors table in the BookShopDB database

USE BookShopDB
GO
CREATE TRIGGER dbo.insertindicator
ON dbo.authors
AFTER INSERT
AS
PRINT The insert trigger fired.
The CREATE TRIGGER statement creates a trigger named InsertIndicator and

applies the trigger to the Authors table of the BookShopDB database. When an
insert to the Authors table occurs, this trigger fires and prints a message on the
Grids tab in the Results pane.
CREATE TRIGGER dbo.updateindicator
ON dbo.authors
AFTER UPDATE
AS
PRINT The update trigger fired.
GO

CREATE TRIGGER dbo.deleteindicator
ON dbo.authors
AFTER DELETE
AS
IF @@ROWCOUNT <> 0
PRINT The delete trigger fired.
The CREATE TRIGGER statements create triggers named UpdateIndicator and

DeleteIndicator. These triggers are applied to the Authors table in the BookShopDB database. When an UPDATE or DELETE occurs, these triggers print a
message on the Grids tab in the Results pane. Notice that the DeleteIndicator
trigger tests the @@ROWCOUNT value. If one or more rows are deleted, the
message prints.
_
To test the triggers on the Authors table
INSERT INTO authors (firstname, lastname, yearborn, yeardied)
VALUES (Max, Doe, 1962, N/A)
A record is inserted into the Authors table, and the InsertIndicator trigger fires
and prints the triggers message to the Messages tab of the Results pane.
UPDATE authors
SET authors.firstname = Tucker
WHERE authors.firstname = Max
A record is updated in the Authors table, and the UpdateIndicator trigger fires
DELETE authors where firstname = Tucker
A record is deleted in the Authors table, and the DeleteIndicator trigger fires
_
To rename, modify, and view a trigger
1. In the Editor pane of the Query window, enter the following stored procedure
code:
sp_rename @objname=insertindicator, @newname=insupdcontrol
The sp_rename system stored procedure renames the InsertIndicator trigger to

InsUpdIndicator. Later, you will modify the trigger to fire upon INSERT and
UPDATE events.
The Messages tab of the Results pane cautions you that renaming an object
could cause scripts and stored procedures to fail. The message also indicates
that the rename operation was successful.
Implementation
3. In the Editor pane of the Query window, enter and execute the following stored
procedure code:
sp_helptrigger @tabname = authors
The sp_helptrigger system stored procedure displays a list of triggers applied to

the Authors table.
ALTER TRIGGER dbo.insupdcontrol
ON dbo.authors
INSTEAD OF INSERT, UPDATE
AS
PRINT Inserts and updates are not allowed at this time.
The trigger modification converts the renamed trigger into an INSTEAD OF

trigger that prevents any inserts and updates to the Authors table. You might
want to use this type of trigger to temporarily prevent changes to a table. You
can disable and enable triggers by using the ALTER TABLE statement.
SET NOCOUNT ON
SET NOCOUNT OFF
The INSTEAD OF trigger fires and displays a message stating that updates are
not allowed at this time. NOCOUNT is enabled so that a row-affected message
does not appear in the Messages tab of the Results pane.
6. Run a SELECT statement against the Authors table to verify that no record was
added.
7. In the Editor pane of the Query window, enter and execute the following stored
procedure code:
sp_helptext @objname=insupdcontrol
The stored procedure displays the contents of the InsUpdControl trigger.

_
To disable and drop a trigger
ALTER TABLE authors DISABLE TRIGGER insupdcontrol
The ALTER TABLE statement disables the InsUpdControl trigger on the

Authors table.
SELECT * FROM Authors where Firstname = Max
A record is successfully inserted into the Authors table, and the record appears
in the Grids tab of the Results pane.
DROP TRIGGER insupdcontrol, updateindicator, deleteindicator
DELETE authors where firstname = Max
The DROP TRIGGER statement deletes all three triggers applied to the Authors
table. The DELETE statement removes the record added to the Authors table.
Lesson Summary
In this lesson, you learned how to create a trigger by using the CREATE TRIGGER
statement. You must specify the table or view to which the trigger is applied, the
event or events that fire the trigger, and any Transact-SQL code that should run
when the trigger fires. You have the option of specifying the trigger class, AFTER
or INSTEAD OF. AFTER is synonymous with FOR and is the more common trigger
to apply to tables. INSTEAD OF can be applied to tables or views. When using
CREATE TRIGGER, you must use it as the first statement in a batch. You can also
use Enterprise Manager to create triggers.
Triggers are managed using tools and Transact-SQL statements. In Enterprise
Manager, you can perform a number of trigger management tasks using the Manage
Triggers option. To modify a trigger in Query Analyzer, use ALTER TRIGGER.
To rename a trigger, use the sp_rename system stored procedure. To view the contents
of a trigger, use the sp_helptext system stored procedure. To view a triggers
properties, use the sp_helptrigger system stored procedure or the OBJECTPROPERTY

function. Triggers are deleted using the DROP TRIGGER statement and are
enabled or disabled using the ALTER TABLE statement.
Implementation
Lesson 3: Programming Triggers

Create triggers to apply business logic to the database.
Determine how to use the Inserted and Deleted pseudo tables.
Use common trigger system functions.
The Inserted and Deleted Pseudo Tables

When an INSERT, UPDATE, or DELETE trigger fires, the event creates one or
more pseudo tables (also known as logical tables). These logical tables can be
thought of as the transaction logs of the event. There are two types of logical tables:
the Inserted table and the Deleted table. An insert or update event creates an
Inserted logical table. The Inserted logical table contains the record set that has
been added or changed. The UPDATE trigger also creates a Deleted logical table.
The Deleted logical table contains the original record set as it appeared before the
update. The following example creates a trigger that displays the contents of the
Inserted and Deleted tables following an update event to the Authors table:
CREATE TRIGGER dbo.updatetables
ON dbo.authors
AFTER UPDATE
AS
SELECT Description = The Inserted table:
SELECT * FROM inserted
SELECT Description = The Deleted table:
SELECT * FROM deleted
Following a simple UPDATE statement that changes an authors name from Dean
to Denby, the trigger displays the following results:
The Inserted table:
Straight Denby Oakland CA 94609
The Deleted table:
Straight Dean Oakland CA 94609
The Authors table (trigger table) contains the updated record after the update trigger
runs. When the trigger fires, the update to the Authors table can be rolled back
by programming logic into the trigger. This transaction rollback capability also
applies to INSERT and DELETE triggers.
When a delete trigger fires, the Deleted logical table contains the deleted record
set. The Inserted table is not part of a DELETE event.
Note The SELECT statement appears in the previous code example for illustrative
purposes only. Never use statements in triggers that return a result unless you are
sure that the result returned by the trigger can be handled by any applications that
cause the trigger to fire.
Trigger Syntax, System Commands, and Functions

Now that you understand the purpose of triggers and the various types of triggers,
the next step is to investigate the syntax for creating and altering a trigger. Functions
and system commands augment triggers by allowing you to implement business
logic in the trigger.
UPDATE (column_name) and (COLUMNS_UPDATED())

Clauses
Two important clauses that are part of the CREATE TRIGGER and ALTER TRIGGER
statements are UPDATE (column_name) and (COLUMNS_UPDATED()).
These two clauses can be part of an Insert or Update trigger and can appear anywhere
in the CREATE TRIGGER or ALTER TRIGGER statement.
The IF UPDATE (column_name) clause determines whether an INSERT or
UPDATE event occurred to the column named column_name. If you need to specify
more than one column, separate each column name with UPDATE
(column_name). For example, the following code segment checks to determine
whether the First_Name and Last_Name columns were inserted or updated and
does something as a result of an INSERT or UPDATE to either of these columns:
IF UPDATE (first_name) OR UPDATE (Last_Name)
BEGIN
Do some conditional processing when either of these columns are upda
ted.
END
Because of deferred name resolution, the column specified by column_name does

not need to exist when the trigger is applied to the table. However, the column must
exist when the trigger fires. For more information about deferred name resolution,
refer to Chapter 8, Implementing Stored Procedures.

If the column_name is replaced with a value, the UPDATE clause returns TRUE.
The (COLUMNS_UPDATED()) clause also tests for updated columns. Instead of
returning true or false, (COLUMNS_UPDATED()) returns a varbinary bit pattern
that indicates which of the tested columns were inserted or updated.
Implementation
The (COLUMNS_UPDATED()) clause is more complex to write than the UPDATE

(column_name) clause, but it returns exactly which tested columns were inserted or
updated. You specify which columns to test by using a bit mask to represent each
column (ordinal) position in the table. The following table shows the first eight columns
and the bit mask assigned to each column:
To test whether columns 4 or 6 were updated, you can use the following code:
IF (COLUMNS_UPDATED() & 40) > 0
The value of 40 is derived from summing 8 for column 4 and 32 for column 6. The
(COLUMNS_UPDATED()) expression tests whether the return value is greater
than 0. In other words, if either or both of the columns are updated, the columns
updated condition is met. If you set (COLUMNS_UPDATED() & 40) = 40, then you
are testing whether both of the columns are updated. Updates to one or the other
column do not meet the columns updated condition.
To test more than eight columns, you must use the SUBSTRING function so that
the trigger knows which bit mask to test. For example, to test for an update to the
ninth column, you can use the following code:
IF ((SUBSTRING(COLUMNS_UPDATED(),2,1)=1))
The SUBSTRING function tells the (COLUMNS_UPDATED()) clause to move to

the second octet of columns and then test for an update to column 1 of the second
octet (which is actually in ordinal position 9). The varbinary return value for this
column is 1. The following table shows the SUBSTRING function necessary to test
columns 9 through 16:
IF ((SUBSTRING(COLUMNS_UPDATED(),2,y)=z))
To test modifications to multiple columns, simply add the bit values for each column.
For example, to test columns 14 and 16, specify 160 (32 + 128) for the z value.
Functions and System Commands

Numerous functions and system commands are used in triggers to implement business
logic. A function commonly used in triggers is @@ROWCOUNT. This function
returns the number of rows affected by the previous Transact-SQL statement in
the trigger. If no rows are affected by an INSERT, UPDATE, or DELETE event, the
trigger still fires. Therefore, use the RETURN system command to exit the trigger
transparently when no table modifications are made.
Column 1 2 3 4 5 6 7 8
Bit Mask 1 2 4 8 16 32 64 128
Column 9 10 11 12 13 14 15 16
y and z 1 2 4 8 16 32 64 128
In the event of an error, you might want to display a message describing the reason
for the error. The RAISERROR system command is used to display error messages.
You can create custom error messages with the sp_addmessage system
stored procedure, or you can display ad hoc error messages when calling the RAISERROR
system command. Refer to SQL Server Books Online for more information
about the sp_addmessage system stored procedure.
The ROLLBACK TRANSACTION system command might also appear in the
Transact-SQL code for the trigger. This command explicitly rolls back the entire
batch of the trigger. A fatal error also causes an implicit rollback. You dont have to
specify ROLLBACK TRANSACTION in the trigger code if your goal is to complete
the transaction in all cases except if a fatal error occurs during the transaction.
Transact-SQL Language Precautions

You can use SELECT and PRINT statements or assign variables in the triggers
code, but using them to return result sets, messages, or values is dangerous. When
an event causes a trigger to fire, the trigger is usually transparent to the user or
application. If the application isnt designed to handle return code, such as a result
set from a SELECT statement, then the application might fail. Using a SELECT
statement to provide a value to a conditional statement is perfectly acceptable. For
example, you might want to use a SELECT statement to test for the existence of a
value and return that value to the IF EXISTS statement so that additional processing
is performed. If you need to assign variables in a triggers code, include SET
NOCOUNT ON in the trigger code.
The following Transact-SQL statements are not allowed in a trigger:
ALTER, CREATE, DROP, RESTORE, and LOAD DATABASE
LOAD and RESTORE LOG
DISK RESIZE and DISK INIT
RECONFIGURE
Common Trigger Programming Tasks

Triggers are used to execute all types of business logic before (INSTEAD OF) or
after (AFTER) an INSERT, UPDATE, or DELETE statement is run against a table
or a view. Triggers are written for common tasks such as the following:
Maintaining running totals and other computed values.
Databases constantly change as data is added, deleted, and modified in tables. In

some cases, a column value in one table is computed from data modifications in
another table. Triggers are ideal for maintaining computed columns. Figure 9.3
shows a trigger used to update the retail price of an item in the Inventory table
when the average wholesale price changes in the Purchasing table.
Implementation
F09BQ03.eps
Figure 9.3. The Inventory and Purchasing tables.
The following trigger is applied to the Purchasing table. It calculates the average
wholesale cost of inventory and increases the price by 30 percent, in addition to
updating the retail_price column of the inventory table with the new value:
CREATE TRIGGER Retail_Price_Update
ON purchasing
AFTER INSERT, UPDATE, DELETE AS
SET NOCOUNT ON
IF EXISTS (SELECT item_num FROM inserted)
BEGIN
UPDATE inventory
SET retail_price =
(SELECT (SUM(pur.total_cost)/SUM(pur.qty_ordered) * 1.30)
FROM purchasing pur INNER JOIN inserted ins
ON pur.item_num = ins.item_num)
FROM inventory inv, inserted ins
WHERE inv.item_num = ins.item_num
END
ELSE IF EXISTS (SELECT item_num from deleted)
BEGIN
UPDATE inventory
SET retail_price =
(SELECT (SUM(pur.total_cost)/SUM(pur.qty_ordered) * 1.30)
FROM purchasing pur INNER JOIN deleted del
ON pur.item_num = del.item_num)
FROM inventory inv, deleted del
WHERE inv.item_num=del.item_num
END
ELSE
BEGIN
RAISERROR (The retail price has not been adjusted for the product.,
16, 1)
RETURN
END
The trigger uses the SET NOCOUNT ON statement so that when the trigger fires
and updates information in the Inventory table, the SELECT statement result is not
displayed. Conditional processing checks for the existence of the Inserted or
Deleted tables. If neither the Inserted nor Deleted tables contain records, the trigger
inventory
item_num
item_desc
qty_in_stock
retail inventory
purchasing
order_id
item_num
wholesale_price
qty_ordered
total cost
uses RAISERROR to display an ad hoc message that no prices were adjusted. You
can use sp_addmessage to add a custom message to the SysMessages system table
and then specify the message number in place of the custom message.
Creating audit records. For security reasons or to simply track activity on a
table (or tables) in the database, you can create a trigger to update a table with
data inserted, updated, or deleted from another table or view.
Invoking external actions. A trigger can specify an action outside of standard
database processing to occur when it fires. For example, in Lesson 2 you

saw an example of using the xp_sendmail extended stored procedure in a trigger
to send a message to an e-mail account when the trigger fires.
Implementing complex data integrity. Sometimes standard data integrity
measures are not enough. For example, the cascading delete action deletes
records in other tables when a delete action would violate referential integrity
between the tables. However, you might not want to allow a cascading delete
action to occur. You could use an INSTEAD OF trigger to delete records from
related tables but then log the deleted result to another table for later review. If
you use an INSTEAD OF trigger to delete records, you cannot implement a
delete action by using cascading referential integrity. To accomplish the same
task, you must program the cascading delete action in the trigger.
Exercise 3: Creating a Trigger to Update a Column Value

In this exercise, you will create and test a trigger that updates the value to 1 in the
Sold column of the Books table in BookShopDB. You will add conditional processing
so that if the book is returned, the Sold column is updated with a value of 0.
_
To create an INSERT trigger to apply to the BookOrders table

CREATE TRIGGER dbo.update_book_status
ON dbo.bookorders
AFTER INSERT
AS
UPDATE books
SET Sold = 1
WHERE titleid =
(SELECT bo.titleid
FROM bookorders bo INNER JOIN inserted i
ON bo.orderid = i.orderid)
The CREATE TRIGGER statement creates a trigger named

Update_Book_Status and applies the trigger to the BookOrders table of the
BookShopDB database. When an insert to the BookOrders table occurs, this
trigger fires and updates the Sold column for the matching TitleID value of the
Books table.
Implementation
_
To alter the trigger to accommodate BookOrders table deletions and updates
ALTER TRIGGER dbo.update_book_status
ON dbo.bookorders
AFTER INSERT, DELETE
AS
SET NOCOUNT ON
IF EXISTS (SELECT * FROM inserted)
BEGIN
UPDATE books
SET Sold = 1
WHERE titleid =
(SELECT bo.titleid
END
ELSE
BEGIN
UPDATE books
SET Sold = 0
WHERE titleid =
(SELECT d.titleid
FROM books b INNER JOIN deleted d
ON b.titleid = d.titleid)
END
The ALTER TRIGGER statement modifies the trigger named

Update_Book_Status and applies the trigger to the BookOrders table of the
BookShopDB database. The DELETE event appears after the INSERT statement
in the third line of code. When a delete in the BookOrders table occurs,
this trigger fires and updates the Sold column to 0 for the matching TitleID.
This business logic is important to accommodate books that are returned.
Notice that the SELECT statement for the delete condition (after the ELSE
clause) matches the TitleID in the books table and the TitleID in the Deleted
table. This modification is necessary because the BookOrders table no longer
contains the deleted record.
2. The previous code does not handle updates. The only update that is relevant to
the Books table is an update to the TitleID column of the BookOrders table. If
the OrderID is changed in the BookOrders table, the book should still have a
Sold value of 1. You must be able to handle updates to the TitleID value. In the
Editor pane of the Query window, enter and execute the following code:
ALTER TRIGGER dbo.update_book_status
ON dbo.bookorders
AFTER INSERT, UPDATE, DELETE
AS
SET NOCOUNT ON
IF EXISTS (SELECT * FROM inserted)

BEGIN
UPDATE books
SET Sold = 1
WHERE titleid =
(SELECT bo.titleid
END
IF EXISTS (SELECT * FROM deleted)
BEGIN
UPDATE books
SET Sold = 0
WHERE titleid =
(SELECT d.titleid
FROM books b INNER JOIN deleted d
ON b.titleid = d.titleid)
END
The trigger is modified to include UPDATES. Notice that the ELSE clause has
been removed. An UPDATE event always creates both the Inserted and Deleted
tables. Therefore, the first part of the code sets the Sold status to 1 for the new
TitleID value. The second part of the code detects the Deleted table and sets the
Sold status for the original TitleID to 0.
_
To test the trigger
SET IDENTITY_INSERT orders ON
INSERT INTO orders
(orderid, customerid, employeeid, amount, orderdate, deliverydate, pa
ymentid, statusid)
VALUES (20, 10, 1, 500, GETDATE(), GETDATE() + 5, 2, 1)
SET IDENTITY_INSERT orders OFF
GO
An order is inserted into the Orders table.

INSERT INTO bookorders
(orderid, titleid)
values (20, carr9675)
A book order for CustomerID 20 for TitleID carr9675 is inserted into the
BookOrders table.
SELECT * from Books where titleid = carr9675
This command verifies that the Sold status for this book has changed to 1.
UPDATE bookorders
set titleID = aust1234 where titleid = carr9675
Implementation
SELECT * from Books WHERE titleid = carr9675 OR titleid = aust1234
This command verifies that the Sold status for the original TitleID is 0 and that
the new TitleID is 1.
DELETE bookorders WHERE titleid = aust1234
This command removes the book order from the BookOrders table, and the
trigger changes the Sold status back to 0.
SELECT * from Books WHERE titleid = aust1234
DROP TRIGGER dbo.update_book_status
This command removes the trigger from the BookOrders table.
Lesson Summary
In this lesson, you learned how to program triggers. Triggers create two logical
tables when an INSERT, UPDATE, or DELETE event occurs in a table to which a
trigger is applied. These tables enable you to determine exactly what data modifications
were made to a table when the trigger fired. Detecting data modifications is
an essential step toward programming business logic into triggers. CREATE and
ALTER TRIGGER syntaxes include two useful clauses for detecting column inserts
or updates: UPDATE (column_name) and (COLUMNS_UPDATED()). The
UPDATE (column_name) clause enables you to take an action based on modifications
occurring to a specific column. The (COLUMNS_UPDATED()) clause
enables you to detect multiple changes in columns designated by a varbinary bit
mask value. The first eight columns are represented by a bit mask ranging from 1
for column 1 to 128 for column 8. Column changes beyond column eight can be
detected using the SUBSTRING function.
Other functions exist besides SUBSTRING and system commands that are commonly
used in triggers. The @@ROWCOUNT function returns the number of rows
affected by a table modification. The RAISERROR system command displays
either custom messages or messages contained in the SysMessages system table.
Another important system command used in triggers is ROLLBACK TRANSACTION.
This command enables you to control events that cause the UPDATE,
INSERT, or DELETE event to be backed out. Use SET NOCOUNT ON in a trigger
to prevent it from returning the rows-affected message to the calling application.
Triggers are often used to maintain running totals or other computed values across
tables, to create audit records to track table data modifications, to invoke external
actions, and to implement complex data integrity features.
Review
then try the question again. You can find answers to the questions in the Appendix,
Questions and Answers.
1. You have applied constraints, an INSTEAD OF trigger, and three AFTER triggers
to a table. A colleague tells you that there is no way to control trigger order
for the table. Is he correct? Why or why not?
2. You need to make sure that when a primary key is updated in one table, all foreign
key references to it are also updated. How should you accomplish this task?
3. Name four instances when triggers are appropriate.
4. When a trigger fires, how does it track the changes that have been made to the
modified table?
5. Name a table deletion event that does not fire a DELETE trigger.
6. Name a system stored procedure and a function used to view the properties of a
trigger.
7. Using Transact-SQL language, what are two methods to stop a trigger from
running?
8. Write a (COLUMNS_UPDATED()) clause that detects whether columns 10 and
11 are updated.
9. Name three common database tasks accomplished with triggers.
10. What command can you use to prevent a trigger from displaying row count
information to a calling application?
11. What type of event creates both Inserted and Deleted logical tables?
12. Is it possible to instruct a trigger to display result sets and print messages?
341
Implementing Views
About This Chapter
A view is a virtual table whose contents are defined by a query. Like a real table, a
view consists of a set of named columns and rows of data. However, a view does
not exist as a stored set of data values in a database. The rows and columns of data
come from tables referenced in the query that defines the view and are produced
dynamically when the view is referenced. In this chapter, you will be introduced to
views and the various functionalities that they support. You will also learn how to
create, modify, and delete views. Finally, you will learn how to use views to insert,
update, and modify data.
Before You Begin

Server computer.
Chapter 4, Implementing SQL Server Databases and Tables, Chapter 5, Implementing

Data Integrity, and Chapter 7, Managing and Manipulating Data.
Implementation
Lesson 1: Introduction to Views

Views are generally used to focus, simplify, and customize each users perception
of the database. You can use a view as a security mechanism by allowing a user to
access data through the view without granting the user permission to directly
access the underlying base tables of the view. You can also use views to improve
performance and to partition data when you are copying data to and from SQL
Server 2000. This lesson will introduce you to views and the various functionalities
that they support.
Define what a view is and describe the functionalities that views support.
Overview of Views
A view acts as a filter on the underlying tables referenced in the view. The query
that defines the view can be from one or more tables or from other views in the current
database or other databases. You can also use distributed queries to define
views that use data from multiple heterogeneous sources. This functionality is useful,
for example, if you want to combine similarly structured data from different
servers, each of which stores data for a different region of your organization.
A view can be thought of as either a virtual table or a stored query. The data accessible
through a standard view is not stored in the database as a distinct object. What
is stored in the database is a SELECT statement. The result set of the SELECT
statement forms the virtual table returned by the view. A user can use this virtual
table by referencing the view name in Transact-SQL statements in the same way a
table is referenced.
Figure 10.1 shows a view based on a SELECT statement that retrieves data from the
Titles table and the Publishers table in the Pubs database.
There are no restrictions on querying through views and few restrictions on modifying
data through them. In addition, a view can reference another view.
You can use a view to perform any or all of the following functions:
Restricting a user to specific rows in a table
Restricting a user to specific columns
Joining columns from multiple tables so that they look like a single table
Aggregating information instead of supplying details
Chapter 10 Implementing Views 343
Views can be used to partition data across multiple databases or instances of SQL
Server 2000. Partitioned views enable you to distribute database processing across
a group of servers.
f10bq01
Figure 10.1. A view based on data from two tables.
SQL Server 2000 also supports indexed views, which greatly improve the performance
of complex views such as those usually found in data warehouses or other

decision support systems. With a standard view, the result set is not saved in the
database. Rather, it is dynamically incorporated into the logic of the statement and
is built dynamically at run time.
Complex queries, however, such as those in decision support systems, can reference
large numbers of rows in base tables and aggregate large amounts of information
into relatively concise aggregates (such as sums or averages). SQL Server
2000 supports creating a clustered index on a view that implements such a complex
query. When the CREATE INDEX statement is executed, the result set of the view
SELECT is stored permanently in the database. Future SQL statements that reference
the view will have substantially better response times. Modifications to the
base data are automatically reflected in the view.
Scenarios for Using Views

You can use views in a variety of ways to return data.
title_id title
View
publishers table
titles table
type pub_id price advance royalty ytd_sales
BU1023
BU1111
BU2075
BU7832
MC2222
MC3021
The Busy Executive's Database Gui
Cooking with Compter: Surreptition
You Can Combat Computer Stress!
Straight Talk About Computers
Silicon Valley Gastronomic Treats
The Gourmet Microwave
business
business
business
business
mod_cook
mod_cook
19.99
11.95
2.99
19.99
19.99
2.99
10
10
24
10
12
24
4095
3876
18722
4095
2032
22246
5,000.00
5,000.00
10.125.00
5,000.00
0.00
15,000.00
1389
1389
0736
1389
0877
0877
pub_id pub_name city
0736
0877
1389
1622
1756
MA
DC
CA
IL
TX
Boston
Washington
Berkeley
Chicago
Dallas
title price
The Busy Executive's Database Gui
Cooking with Compter: Surreptition
You Can Combat Computer Stress!
New Moon Books
Binnet & Hardley
Algodata infosystems
Five Lakes Publishing
Ramona Publishers
19.99
11.95
2.99
New Moon Books
Implementation
To Focus on Specific Data

Views enable users to focus on specific data that interests them and on the specific
tasks for which they are responsible. You can leave out unnecessary data in the
view. This action also increases the security of the data, because users can see only
the data that is defined in the view and not the data in the underlying table.
To Simplify Data Manipulation

Views can simplify how users manipulate data. You can define frequently used
joins, UNION queries, and SELECT queries as views so that users do not have to
specify all of the conditions and qualifications each time an additional operation is
performed on that data. For example, a complex query that is used for reporting
purposes and that performs subqueries, outer joins, and aggregation to retrieve data
from a group of tables can be created as a view. The view simplifies access to the
data because the underlying query does not have to be written or submitted each
time the report is generated. The view is queried instead.
You can also create inline user-defined functions that operate logically as parameterized
views (views that have parameters in WHERE-clause search conditions).
To Customize Data
Views enable different users to see data in different ways, even when they are using
the same data concurrently. This feature is particularly advantageous when users
who have many different interests and skill levels share the same database. For
example, a view can be created that retrieves only the data for the customers with
whom an account manager deals. The view can determine which data to retrieve
based on the login ID of the account manager who uses the view.
To Export and Import Data

You can use views to export data to other applications. For example, you might
want to use the Stores and Sales tables in the Pubs database to analyze sales data in
Microsoft Excel. To perform this task, you can create a view based on the Stores
and Sales tables. You can then use the bcp utility to export the data defined by the
view. Data can also be imported into certain views from data files by using the bcp
utility or the BULK INSERT statement, providing that rows can be inserted into the
view by using the INSERT statement.
To Combine Partitioned Data
The Transact-SQL UNION set operator can be used within a view to combine the
result of two or more queries from separate tables into a single result set. This display
appears to the user as a single table (called a partitioned view). For example, if
one table contains sales data for Washington and another table contains sales data
for California, a view could be created from the UNION of those tables. The view
represents the sales data for both regions.
To use partitioned views, create several identical tables, specifying a constraint to

determine the range of data that can be added to each table. The view is then created
by using these base tables. When the view is queried, SQL Server automatically
determines which tables are affected by the query and references only those
tables. For example, if a query specifies that only sales data for the state of Washington
is required, SQL Server reads only the table containing the Washington
sales data, no other tables are accessed.
Partitioned views can be based on data from multiple heterogeneous sources (such
as remote servers), not just from tables in the same database. For example, to combine
data from different remote servers (each of which stores data for a different
region of your organization), you can create distributed queries that retrieve data
from each data source, and you can then create a view based on those distributed
queries. Any queries read only data from the tables on the remote servers that contain
the data requested by the query. The other servers referenced by the distributed
queries in the view are not accessed.
When you partition data across multiple tables or multiple servers, queries accessing
only a fraction of the data can run faster because there is less data to scan. If the
tables are located on different servers or on a computer that has multiple processors,
each table involved in the query can also be scanned in parallel, thereby
improving query performance. Additionally, maintenance tasks (such as rebuilding
indexes or backing up a table) can be executed more quickly.
By using a partitioned view, the data still appears as a single table and can be queried
as such without having to reference the correct underlying table manually.
Partitioned views are updateable if either of these conditions is met:
An INSTEAD OF trigger is defined on the view with logic to support INSERT,
UPDATE, and DELETE statements.
Both the view and the INSERT, UPDATE, and DELETE statements follow the
rules defined for updateable, partitioned views.
Lesson Summary
Views are generally used to focus, simplify, and customize each users perception of
the database. A view acts as a filter on the underlying tables referenced in the view.
A view can be thought of as either a virtual table or a stored query. There are no
restrictions on querying through views, and few restrictions exist on modifying data
through them. Views enable you to focus on specific data, simplify data manipulation,
customize data, export and import data, and combine partitioned data.
Implementation
Lesson 2: Creating, Modifying, and

Deleting
Views
As you learned in Lesson 1, a view is simply a SELECT query saved in the database.
You can create a view as you would many other objects in a database, and
once that view is created, you can modify the view or delete it. In this lesson, you
will learn how to create views (including indexed views and partitioned views),
modify those views, and then delete them.
Create basic views, indexed views, and partitioned views.
Modify and delete views.
Creating Views
You can create views only in the current database. The tables and views referenced by
the new view can exist in other databases or even in other servers, however, if the view
is defined with distributed queries. View names must follow the rules for identifiers
and must be unique for each user. Additionally, the name must not be the same as any
tables owned by that user. You can build views on other views and on procedures that
reference views. SQL Server 2000 enables views to be nested up to 32 levels.
When creating a view, you must adhere to the following restrictions:
You cannot associate rules or DEFAULT definitions with views.
You cannot associate AFTER triggers with views, only INSTEAD OF triggers.
The query that defines the view cannot include the ORDER BY, COMPUTE, or
COMPUTE BY clauses or the INTO keyword.
You cannot define full-text index definitions on views.
You cannot create temporary views, and you cannot create views on temporary
tables.
Views or tables that participate in a view created with the SCHEMABINDING
clause cannot be dropped unless the view is dropped or changed so that it no

longer has schema binding. In addition, ALTER TABLE statements on tables
that participate in views with schema binding will fail if these statements affect
the view definition.
You cannot issue full-text queries against a view, although a view definition can
include a full-text query if the query references a table that has been configured
for full-text indexing.
You must specify the name of every column in the view if any of the columns in
the view are derived from an arithmetic expression, a built-in function, a constant,
or if two or more of the columns in the view would otherwise have the
same name (usually because the view definition includes a join and the columns
from two or more different tables have the same name).
In addition, you must specify the name of every column in the view if you want
to give any column in the view a name that is different from the column from
which it is derived. (You can also rename columns in the view.) A view column
inherits the data type of the column from which it is derived, whether or not you
rename it. Note that this restriction does not apply if a view is based on a query
containing an outer join, because columns might change from not allowing null
values to allowing them. Otherwise, you do not need to specify column names
when creating the view. SQL Server gives the columns of the view the same
names and data types as the columns in the query that defines the view. The
select list can be a full or partial list of the column names in the base tables.
To create a view, you must be granted permission to do so by the database
owner, and you must have appropriate permissions for any tables or views referenced
in the view definition.
By default, as rows are added or updated through a view, they disappear from the
scope of the view when they no longer fall into the criteria of the query that defines
the view. For example, a view can be defined that retrieves all rows in which the
employees salary is less than $30,000. If an employees salary is increased to
$32,000, then querying the view no longer displays that particular employee
because the salary does not conform to the criteria set by the view. However, the
WITH CHECK OPTION clause forces all data modification statements executed
against the view to adhere to the criteria set within the SELECT statement that
defines the view. If you use this clause, rows cannot be modified in a way that
causes them to disappear from the view. Any modification that would cause this situation
to happen is canceled, and an error is displayed.
Note The WITH CHECK OPTION on a view does not affect the underlying
tables when you modify those tables directly. Only the updates that are made
through the view itself are affected by WITH CHECK OPTION.
The definition of a view can be encrypted to ensure that its definition cannot be
obtained by anyone, including the owner of the view.
Implementation
Creating Standard Views

You can use Enterprise Manager to create a view, or you can use the CREATE
VIEW statement in Transact-SQL. In the following example, a CREATE VIEW
statement is used to define a SELECT query that returns data from the Northwind
database:
USE Northwind
GO
CREATE VIEW CustomerOrders
AS
SELECT o.OrderID, c.CompanyName, c.ContactName
FROM Orders o JOIN Customers c
ON o.CustomerID = c.CustomerID
In this statement, you are creating the CustomerOrders view in the Northwind database.
The view uses a SELECT statement to select the order ID from the Orders
table and the company name and contact name from the Customers table. A join
connects the two tables.
Creating Indexed Views

Views are also known as virtual tables because the result set returned by the view
has the same general form as a table (with columns and rows), and views can be
referenced like tables in SQL statements. The result set of a standard view is not
stored permanently in the database. Each time a query references the view, SQL
Server 2000 dynamically merges the logic needed to build the view result set into
the logic needed to build the complete query result set from the data in the base
tables. The process of building the view result is called materializing the view.
For a standard view, the overhead of dynamically building the result set for each
query that references the view can be substantial if the view involves complex processing
of large numbers of rows (such as aggregating large amounts of data) or
joining many rows. If such views are frequently referenced in queries, you can
improve performance by creating a unique clustered index on the view. When a
unique clustered index is created on a view, the view is executed and the result set is
stored in the database in the same way that a table with a clustered index is stored.
Note You can create indexed views only if you install Microsoft SQL Server 2000
Enterprise Edition or Microsoft SQL Server 2000 Developer Edition.
Another benefit of creating an index on a view is that the optimizer starts using the
view index in queries that do not directly name the view in the FROM clause.
Existing queries can benefit from the improved efficiency of retrieving data from
the indexed view without having to be recoded.
Creating a clustered index on a view stores the data as it exists at the time the index
is created. An indexed view also automatically reflects modifications made to the
data in the base tables after the index is created, the same way as an index created
on a base table. As modifications are made to the data in the base tables, they are
also reflected in the data stored in the indexed view. Because the views clustered
index must be unique, SQL Server can more efficiently find the index rows affected
by any data modification.
Indexed views can be more complex to maintain than indexes on base tables. You
should create an index on a view only if the improved speed in retrieving the result
outweighs the increased overhead of making modifications. This improvement usually
occurs for views that are mapped over relatively static data, process many
rows, and are referenced by many queries.
A view must meet the following requirements before you can create a clustered
index on it:
The ANSI_NULLS and QUOTED_IDENTIFIER options must have been set to
ON when the CREATE VIEW statement was executed. The OBJECTPROPERTY

function reports this setting for views through the ExecIsAnsiNullsOn or
ExecIsQuotedIdentOn properties.
The ANSI_NULLS option must have been set to ON for the execution of all
CREATE TABLE statements that create tables referenced by the view.
The view must not reference any other views, only base tables.
All base tables referenced by the view must be in the same database as the view
and must have the same owner as the view.
The view must be created with the SCHEMABINDING option. SCHEMABINDING
binds the view to the schema of the underlying base tables.
User-defined functions referenced in the view must have been created with the
SCHEMABINDING option.
Tables and user-defined functions must be referenced by two-part names. Onepart,
three-part, and four-part names are not allowed.
All functions referenced by expressions in the view must be deterministic. The
IsDeterministic property of the OBJECTPROPERTY function reports whether a

user-defined function is deterministic.
If GROUP BY is not specified, the view select list cannot contain aggregate
expressions.
If GROUP BY is specified, the view select list must contain a
COUNT_BIG(*) expression, and the view definition cannot specify HAVING,

CUBE, or ROLLUP.
A column resulting from an expression that either evaluates to a float value or
uses float expressions for its evaluation cannot be a key of an index in an

indexed view or table.
Implementation
In addition to the previous restrictions, the SELECT statement in the view cannot
contain the following Transact-SQL syntax elements:
The asterisk ( * ) syntax to specify columns in a select list
A table column name used as a simple expression that is specified in more than
one view column
A derived table
Rowset functions
A UNION operator
Subqueries
Outer or self joins
The TOP clause
The ORDER BY clause
The DISTINCT keyword
COUNT(*) (COUNT_BIG(*) is allowed)
The AVG, MAX, MIN, STDEV, STDEVP, VAR, or VARP aggregate functions
A SUM function that references a nullable expression
The full-text predicates CONTAINS or FREETEXT
The COMPUTE or COMPUTE BY clauses
Creating the Index

After you create a view, you can create an index on that view, assuming that the
view adheres to the requirements for an indexed view. The first index created on a
view must be a unique clustered index. After the unique clustered index has been
created, you can create additional non-clustered indexes. The naming conventions
for indexes on views are the same as for indexes on tables. The only difference is
that the table name is replaced with the view name.
The CREATE INDEX statement must meet the following requirements in addition
to the normal CREATE INDEX requirements:
The user executing the CREATE INDEX statement must be the views owner.
The NUMERIC_ROUNDABORT option must be set to OFF.
The view cannot include text, ntext, or image columns (even if they are not referenced
in the CREATE INDEX statement).
If the SELECT statement in the view definition specifies a GROUP BY clause,
the key of the unique clustered index can reference only columns specified in
the GROUP BY clause.
The following SET options must be set to ON when the CREATE INDEX statement
is executed:
ANSI_NULLS
ANSI_PADDING
ANSI_WARNINGS
ARITHABORT
CONCAT_NULL_YIELDS_NULL
QUOTED_IDENTIFIERS
Indexes are discussed in more detail in Chapter 11, Implementing Indexes.
Creating Partitioned Views

A partitioned view joins horizontally partitioned data from a set of member tables
across one or more servers, making the data appear as if it is from one table. SQL
Server 2000 distinguishes between local and distributed partitioned views. In a
xxxlocal partitioned view, all participating tables and the view reside on the same
instance of SQL Server. In a distributed partitioned view, at least one of the participating
tables resides on a different (remote) server. In addition, SQL Server 2000

differentiates between partitioned views that are updateable and views that are
read-only copies of the underlying tables.
Distributed partitioned views can be used to implement a federation of database
servers. A federation is a group of servers that is administered independently but that
cooperates to share the processing load of a system. Forming a federation of database
servers by partitioning data is the mechanism that enables you to scale out a set
of servers to support the processing requirements of large, multi-tiered Web sites.
Before implementing a partitioned view, you must first partition a table horizontally.
The original table is replaced with several smaller member tables. Each member
table has the same number of columns as the original table, and each column
has the same attributes (such as data type, size, and collation) as the corresponding
column in the original table. If you are creating a distributed partitioned view, each
member table is on a separate member server. For the greatest location transparency,
the name of the member databases should be the same on each member
server, although this setup is not a requirement (for example, Server1.CustomerDB,
Server2.CustomerDB, and Server3.CustomerDB).
You should design the member tables so that each table stores a horizontal slice of
the original table, based on a range of key values. The ranges are based on the data
values in a partitioning column. The range of values in each member table is
enforced by a CHECK constraint on the partitioning column, and ranges cannot
overlap. For example, you cannot have one table with a range from 1 through
200,000 and another with a range from 150,000 through 300,000, because it would
not be clear which table contains the values from 150,000 through 200,000.
Implementation
For example, suppose you are partitioning a Customer table into three tables. The
CHECK constraint for these tables should be defined as follows:
-- On Server1:
CREATE TABLE Customer_33
(CustomerID INTEGER PRIMARY KEY
CHECK (CustomerID BETWEEN 1 AND 32999),
... -- Additional column definitions)
-- On Server2:
-- On Server3:
After creating the member tables, define a distributed partitioned view on each
member server, with each view having the same name. This setup lets queries referencing
the distributed partitioned view name run on any of the member servers.
The system operates as if a copy of the original table is on each member server, but
each server has only a member table and a distributed partitioned view. The location
of the data is transparent to the application.
You can build the distributed partitioned views by taking the following steps:
1. Add linked server definitions on each member server containing the connection
information needed to execute distributed queries on the other member
servers. This action gives a distributed partitioned view access to data on the
other servers.
2. Set the lazy schema validation option (by using sp_serveroption) for each
linked server definition used in distributed partitioned views. This setting optimizes
performance by ensuring that the query processor does not request metadata
for any of the linked tables until data is actually needed from the remote
member table.
3. Create a distributed partitioned view on each member server. The views should
use distributed SELECT statements to access data from the linked member
server and merge the distributed rows with rows from the local member table.
To create distributed partitioned views for the preceding example, you should take
the following steps:
1. Add a linked server definition named Server2 with the connection information
for Server2 and a linked server definition named Server3 for access to Server3.
2. Create the following distributed partitioned view:

CREATE VIEW Customers AS
SELECT *
FROM CompanyDatabase.TableOwner.Customers_33
UNION ALL
SELECT *
FROM Server2.CompanyDatabase.TableOwner.Customers_66
UNION ALL
SELECT *
FROM Server3.CompanyDatabase.TableOwner.Customers_99
3. Perform the same steps on Server2 and Server3.
Modifying Views
After a view is defined, you can change its name or modify its definition without
dropping and recreating the view, which would cause it to lose its associated permissions.
When you rename a view, adhere to the following guidelines:
The view to be renamed must be in the current database.
The new name must follow the rules for identifiers.
You can rename only views that you own.
The database owner can change the name of any users view.
Altering a view does not affect any dependent objects (such as stored procedures or
triggers) unless the definition of the view changes in such a way that the dependent
object is no longer valid.
To modify a view, you can use Enterprise Manager or the Transact-SQL ALTER
VIEW statement to update the SELECT query, as shown in the following example:
ALTER VIEW CustomerOrders
AS
SELECT o.OrderID, o.OrderDate, c.CompanyName, c.ContactName
FROM Orders o JOIN Customers c
ON o.CustomerID = c.CustomerID
In this statement, you are modifying the select list so that it includes the order date.
The SELECT query in the ALTER VIEW statement replaces the SELECT query
that was defined in the original CREATE VIEW statement.
In addition, you can modify a view to encrypt its definition or to ensure that all data
modification statements executed against the view adhere to the criteria set within
the SELECT statement that defines the view.
Implementation
Deleting Views
After a view has been created, you can delete the view if it is not needed or if you
want to clear the view definition and the permissions associated with it. When a
view is deleted, the tables and the data upon which it is based are not affected. Any
queries that use objects that depend on the deleted view fail when they are next
executed (unless a view with the same name is created). If the new view does not
reference objects expected by any objects dependent on the new view, however,
queries using the dependent objects will fail when executed.
For example, suppose you create a view named MyView that retrieves all columns
from the Authors table in the Pubs database, and this view is deleted and replaced
by a new view named MyView that retrieves all columns from the Titles table
instead. Any stored procedures that reference columns from the underlying
Authors table in MyView now fail because those columns are replaced by columns
from the Titles table instead.
To delete a view, you can use Enterprise Manager or the Transact-SQL DROP
VIEW statement, as shown in the following example:
DROP VIEW CustomerOrders
Exercise 1: Creating and Modifying a View

In this exercise, you will use the CREATE VIEW statement to create a view in the
BookShopDB database, the ALTER VIEW statement to modify this view, and the
DROP VIEW statement to delete the view from the database. To perform this exercise,
you should be logged onto your Windows 2000 Server computer as Administrator.
_
To create the BookAuthorView view in the BookShopDB database

code:
USE BookShopDB
GO
CREATE VIEW BookAuthorView
AS
SELECT a.FirstName, a.LastName, b.Title
FROM Authors a JOIN BookAuthors ba
ON a.AuthorID = ba.AuthorID
JOIN Books b
ON ba.TitleID = b.TitleID
In this statement, you are defining the BookAuthorView view in the BookShopDB database. The CREATE VIEW statement contains a SELECT query
that joins the Authors table to the BookAuthors table and the BookAuthors
table to the Books table. The result set from this query will include the authors
first and last names and the books that this author has written.
3. Execute the Transact-SQL statement.
A message appears in the Messages tab of the Results pane, stating that the
command has been successfully completed.
4. If the Object Browser window is not displayed, open it now.
5. In the object tree of the Object Browser window, locate the new view that you
created.
Notice that the dbo.BookAuthorView node contains several nodes (including

the Columns node and the Indexes node).
6. Expand the Columns node.
Notice that the three columns that were included in the SELECT query of the
CREATE VIEW definition are included in this node.
_
To modify the BookAuthorView view in the BookShopDB database
code:
USE BookShopDB
GO
ALTER VIEW BookAuthorView
AS
SELECT a.FirstName, a.LastName, b.TitleID, b.Title
FROM Authors a JOIN BookAuthors ba
ON a.AuthorID = ba.AuthorID
JOIN Books b
ON ba.TitleID = b.TitleID
Tip You can copy and paste the code from the previous procedure and modify
it to contain an ALTER VIEW statement and the TitleID column.
In this statement, you are adding the TitleID column to the SELECT statement.
The result set will now include the additional column.
3. In the object tree of the Object Browser window, locate the BookAuthorView
view and expand the Columns node.
Notice that the TitleID column has been added to the list of columns.
4. Close Query Analyzer.
Implementation
_
To delete the BookAuthorView view from the BookShopDB database
code:
USE BookShopDB
GO
DROP VIEW BookAuthorView
In this statement, you are deleting the BookAuthorView view from the BookShopDB database.
3. In the object tree of the Object Browser window, locate the Views node for the
BookShopDB database.
Notice that the BookAuthorView view no longer appears.
Note If the BookAuthorView view is still listed in the object tree, you will
need to refresh the screen to update the listings.
Lesson Summary
You can create a view as you would many other objects in a database, and once that
view is created, you can modify the view or delete it. When creating a view, you
must adhere to specific restrictions. You can use Enterprise Manager to create a
view, or you can use the CREATE VIEW statement in Transact-SQL. In addition to
standard views, you can create indexed views. When a unique clustered index is
created on a view, the view is executed and the result set is stored in the database in
the same way as a table with a clustered index is stored. The first index created on a
view must be a unique clustered index. After the unique clustered index has been
created, you can create additional non-clustered indexes. In addition to indexed
views, you can create partitioned views. A partitioned view joins horizontally partitioned
data from a set of member tables across one or more servers, making the
data appear as if it is from one table. After a view is defined, you can change its
name or modify its definition without dropping and recreating the view, which
would cause it to lose its associated permissions. You can also delete a view if it is
not needed or if you want to clear the view definition and the permissions associated
with it. When a view is deleted, the tables and the data upon which it is based
are not affected.
Lesson 3: Accessing Data through

Views
Once a view has been created, you can use the view to access the data that is
returned by the SELECT query defined within that view. Most operations that you
can perform on a query can be performed on a view. In this lesson, you will learn
how to use views to view the data returned by the SELECT query, and you will
learn how to modify that data.
Use a view to view data.
Use a view to insert, update, and delete data.
Viewing Data through Views

There are no restrictions on querying data through views. You can use a view in a
SELECT statement to return data in much the same way as you use a table. The following
SELECT statement enables you to view data returned by the CustomerOrders view in the Northwind database:
USE Northwind
SELECT *
FROM CustomerOrders
As with tables, you can be more specific about the type of data you return in a
view. The following SELECT statement retrieves the OrderID column and the
OrderDate column for any orders made for the QUICK-Stop company:
USE Northwind
SELECT OrderID, OrderDate
FROM CustomerOrders
WHERE CompanyName = quick-stop
ORDER BY OrderID
In this statement, you are also specifying for the result set to be ordered by the
OrderID values.
Modifying Data through Views

Views in all versions of SQL Server are updateable (can be the target of UPDATE,
DELETE, or INSERT statements) as long as the modification affects only one of
the base tables referenced by the view. SQL Server 2000 supports more complex
types of INSERT, UPDATE, and DELETE statements that reference views. For
example, INSTEAD OF triggers can be defined on a view to specify the individual
updates that must be performed against the base tables to support the INSERT,
Implementation
UPDATE, or DELETE statement. Also, partitioned views support INSERT,

UDPATE, and DELETE statements that modify multiple member tables referenced
by the view.
Modifying Data through Basic Views

There are few restrictions on modifying data through a view. However, if a view
does not use an INSTEAD OF trigger or is not an updateable partitioned view, it

can still be updateable, provided it meets the following conditions:
The view contains at least one table in the FROM clause of the view definition.
The view cannot be based solely on an expression.
No aggregate functions (AVG, COUNT, SUM, MIN, MAX, GROUPING,
STDEV, STDEVP, VAR, and VARP) or GROUP BY, UNION, DISTINCT, or

TOP clauses are used in the select list. Aggregate functions, however, can be
used within a subquery defined in the FROM clause, provided that the derived
values generated by the aggregate functions are not modified.
No derived columns are used in the select list. Derived columns are result set
columns formed by anything other than a simple column reference.

Before you modify data through a view without using an INSTEAD OF trigger or
an updateable partitioned view, consider the following guidelines:
All data modification statements executed against the view must adhere to the
criteria set within the SELECT statement defining the view if the WITH
CHECK OPTION clause is used in the definition of the view. If the WITH
CHECK OPTION clause is used, rows cannot be modified in a way that causes
them to disappear from the view. Any modification that would cause this situation
to happen is canceled, and an error is displayed.
SQL Server must be capable of unambiguously resolving the modification
operation to specific rows in one of the base tables referenced by the view. You
cannot use data modification statements on more than one underlying table in a
single statement. Therefore, the columns listed in the UPDATE or INSERT
statement must belong to a single base table within the view definition.
All of the columns in the underlying table that are being updated and that do not
allow null values have values specified in either the INSERT statement or
DEFAULT definitions. This feature ensures that all of the columns in the underlying
table that require values have them.
The modified data in the columns in the underlying table must adhere to the
restrictions on those columns, such as nullability, constraints, DEFAULT definitions,

and so on. For example, if a row is deleted, all of the underlying FOREIGN
KEY constraints in related tables must still be satisfied for the delete to
succeed.
A distributed partition view (remote view) cannot be updated by using a keysetdriven
cursor. This restriction can be resolved by declaring the cursor on the
underlying tables and not on the view itself.

Additionally, to delete data in a view, only one table can be listed in the FROM
clause of the view definition. The READTEXT and WRITETEXT statements cannot
be used with text, ntext, or image columns in a view.
Adding Data through a View

Suppose you create a view in the Northwind database that returns the customer ID
and the company name from the Customers table:
USE Northwind
GO
CREATE VIEW CustomerView
AS
SELECT CustomerID, CompanyName
FROM Customers
To insert data through the CustomerView view, you should use the INSERT statement
(as shown in the following example):
USE Northwind
INSERT CustomerView
VALUES (TEST1, Test Company)
This statement inserts a new row into the Customers table. Because all other columns
in the table permit null values, you do not have to specify a value for those
columns.
Changing Data through a View

To modify data through a view, you should use the UPDATE statement (as shown
in the following example):
USE Northwind
UPDATE CustomerView
SET CustomerID = TEST2
WHERE CustomerID = TEST1
This statement changes the customer ID of Test Company to TEST2.

Implementation
Deleting Data through a View

To delete data through a view, you should use the DELETE statement, as shown in
the following example:
USE Northwind
DELETE CustomerView
WHERE CustomerID = TEST2
This statement deletes the Test Company row from the Customers table.
Modifying Data through Partitioned Views

If a local or distributed partitioned view is not updateable, it can serve only as a
read-only copy of the original table. An updateable partitioned view can exhibit all
of the capabilities of the original table.
A view is considered an updateable partitioned view if it is defined with a set of
SELECT statements whose individual result sets are combined into one by using
the UNION ALL statement. Each individual SELECT statement references one
SQL Server base table. The table can be either a local table or a linked table referenced
using a four-part name, the OPENROWSET function, or the OPENDATASOURCE
function (you cannot use an OPENDATASOURCE or OPENROWSET
function that specifies a pass-through query).
In addition to the rules defined for updateable partitioned views, data modification
statements referencing the view must adhere to the rules defined for INSERT,
UPDATE, and DELETE statements.
Note You can modify data through a partitioned view only if you install
Microsoft SQL Server 2000 Enterprise Edition or Microsoft SQL Server 2000
Developer Edition.
INSERT Statements
INSERT statements add data to the member tables through the partitioned view.
The INSERT statements must adhere to the following rules:
All columns must be included in the INSERT statement even if the column can
be NULL in the base table or has a DEFAULT constraint defined in the base
table.
The DEFAULT keyword cannot be specified in the VALUES clause of the
INSERT statement.
INSERT statements must supply a value that satisfies the logic of the CHECK
constraint defined on the partitioning column for one of the member tables.
INSERT statements are not allowed if a member table contains a column that
has an identity property.

INSERT statements are not allowed if a member table contains a timestamp
column.
INSERT statements are not allowed if there is a self-join with the same view or
with any of the member tables.
UPDATE Statements
UPDATE statements modify data in one or more of the member tables through the
partitioned view. The UPDATE statements must adhere to the following rules:
UPDATE statements cannot specify the DEFAULT keyword as a value in the
SET clause, even if the column has a DEFAULT value defined in the corresponding
member table.
The value of a column with an identity property cannot be changed; however,
the other columns can be updated.
The value of a PRIMARY KEY cannot be changed if the column contains text,
image, or ntext data.
Updates are not allowed if a base table contains a timestamp column.
Updates are not allowed if there is a self-join with the same view or any of the
member tables.
The DEFAULT keyword cannot be specified in the SET clause of the UPDATE
statement.
DELETE Statements
DELETE statements remove data in one or more of the member tables through the
partitioned view. The DELETE statements are not allowed if there is a self-join
with the same view or any of the member tables.
Modifying Data when the INSTEAD OF Trigger Is Used

INSTEAD OF triggers override the standard actions of the triggering statement
(INSERT, UPDATE, or DELETE). For example, an INSTEAD OF trigger can be
defined to perform error or value checking on one or more columns and then to
perform additional actions before inserting the record. For instance, when the value
being updated in an hourly wage column in a payroll table exceeds a specified
value, a trigger can be defined to either produce an error message and roll back the
transaction or insert a new record into an audit log before inserting the record into
the payroll table.
INSTEAD OF triggers can be defined on either tables or views; however,
INSTEAD OF triggers are most useful for extending the types of updates that a
view can support. INSTEAD OF triggers are discussed in more detail in Chapter 9,
Implementing Triggers.
Implementation
Exercise 2: Using the AuthorsBooks View to Access Data
In this exercise, you will create a view on the Authors table that includes only the
first and last names of the authors. You will then use this view to add an author to the
database, modify that author, and then delete the author. To perform this exercise,
you should be logged into your Windows 2000 Server computer as Administrator.
_
To create the AuthorNames view to view data

code:
USE BookShopDB
GO
CREATE VIEW AuthorNames
AS
SELECT FirstName, LastName
FROM Authors
In this statement, you are creating a view that returns the first and last names of
the authors listed in the Authors table of the BookShopDB database.
_
To use the AuthorNames view to view data
code:
USE BookShopDB
SELECT *
FROM AuthorNames
ORDER BY LastName
This statement uses the AuthorNames view to retrieve data. The result set is
ordered by the last names of the authors.
The result set is displayed in the Grids tab of the Results pane.
_
To use the AuthorNames view to insert data
code:
USE BookShopDB
INSERT AuthorNames
VALUES (William, Burroughs)
This statement uses the AuthorNames view to insert a new author.

Transact-SQL code:
SELECT *
FROM Authors
4. Scroll to the last row of the result set.
Notice that William Burroughs has been added to the list of authors. Also
notice that the YearBorn, YearDied, and Description columns have been
assigned the default value of N/A.
_
To use the AuthorNames view to modify data
code:
USE BookShopDB
UPDATE AuthorNames
SET FirstName = John
WHERE LastName = Burroughs
This statement changes the first name of the author whose last name is Burroughs.
Transact-SQL code:
SELECT *
FROM AuthorNames
Notice that William Burroughs has been changed to John Burroughs.
_
To use the AuthorNames view to delete data
code:
USE BookShopDB
DELETE AuthorNames
WHERE LastName = Burroughs
This statement deletes John Burroughs from the Authors table.

Implementation

Transact-SQL code:
SELECT *
FROM Authors
Notice that John Burroughs has been deleted from the Authors table.
_
To delete the AuthorNames view in the BookShopDB database
code:
USE BookShopDB
GO
DROP VIEW AuthorNames
In this statement, you are deleting the BookAuthorView view from the BookShopDB database.
Lesson Summary
Once a view has been created, you can use the view to access the data that is
returned by the SELECT query defined within that view. You can use a view in a
SELECT statement to return data in much the same way as you use a table. SQL
Server also enables you to use views to modify data. In addition to modifying data
through basic views, you can modify data through updateable partitioned views
and views that use INSTEAD OF triggers. If a view does not use an INSTEAD OF
trigger or is not an updateable partitioned view, it can still be updateable provided it
meets specific conditions. If the conditions are met, you can insert, update, or
delete data through the view. A view is considered an updateable partitioned view
if the view is a set of SELECT statements whose individual result sets are combined
into one by using the UNION ALL statement. In addition to the rules defined
for updateable partitioned views, data modification statements referencing the view
must adhere to the rules defined for INSERT, UPDATE, and DELETE statements.
INSTEAD OF triggers override the standard actions of the triggering statement
(INSERT, UPDATE, or DELETE). INSTEAD OF triggers can be defined for either

tables or views; however, INSTEAD OF triggers are most useful for extending the
types of updates that a view can support.
Review
then try the question again. You can find the answers to these questions in the
Appendix, Questions and Answers.
1. What is a view?
2. What functions can a view be used to perform?
3. For what scenarios can views be used?
4. What are at least five restrictions that you must adhere to when creating views?
5. What two tools does SQL Server provide to create a view?
6. Where are the result sets stored for standard views and indexed views?
7. If a view is going to be indexed, what type of index must be the first index created
on that view?
8. Which Transact-SQL statement or statements should you use to change the definition
of a view or to delete that view from the database?
9. What Transact-SQL statement should you use if you want to view all of the
data in the AuthorNames view of the Northwind database?
10. Which Transact-SQL statement or statements should you use to insert, modify,
and delete data through a view?
11. What conditions must a view meet before you can modify data through that
view?
12. When is a view considered to be an updateable partitioned view?

Trigers SP Views

Uploaded by

Copyright:

Available Formats

Trigers SP Views

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Trigers SP Views

Uploaded by

Copyright:

Available Formats

Implementing Stored Procedures

About This Chapter

Before You Begin

SQL Server 2000 Enterprise Edition installed on a Microsoft Windows 2000

as the Windows 2000 Administrator.

Completed the exercises in Chapter 3, Designing a SQL Server Database,

Chapter 4, Implementing SQL Server Databases and Tables, and Chapter 5,

Lesson 1: Introduction to Stored

After this lesson, you will be able to:

Describe the purpose and reasons for using stored procedures.

Explain how SQL Server processes a stored procedure.

Determine when to use stored procedures to complete SQL Server tasks.

Estimated Lesson time: 30 minutes

Purpose and Advantages of Stored Procedures

Categories of Stored Procedures

System Stored Procedures

A common database administration task is viewing information about current database

Chapter 8 Implementing Stored Procedures 271

Local Stored Procedures

Temporary Stored Procedures

the procedure and, like all temporary stored procedures, it is created in

TempDB. Permission to execute a global temporary stored procedure is automatically

You can configure permissions for them.

They arent removed until SQL Server is shut down.

Because this procedure type is created directly in TempDB, it is important to fully

Extended Stored Procedures

SELECT OBJECTPROPERTY(object_id(sp_prepare), IsExtendedProc)

This example returns a value of 1.

This example returns a value of 0.

Remote Stored Procedures

Exercise 1: Exploring Stored Procedures

To view system stored procedures in the Master database

1. Open Query Analyzer and connect to your local server.

@RETURN_VALUE parameter; @loginame is an input parameter. The second

8. Expand the Dependencies node.

To use two methods for viewing the contents of a stored procedure

1. Click once on the dbo.sp_who object.

Dont worry about not understanding everything in this stored procedure. In

Lesson 2: Creating, Executing,

when a procedure is modified. The keywords used to modify a procedure are

After this lesson, you will be able to:

Create and modify a stored procedure in SQL Server.

Execute a stored procedure.

Delete a stored procedure from SQL Server.

Estimated lesson time: 45 minutes

How a Procedure Is Stored

information (such as an auto-generated identification number) to the SysObjects

This query returns the following:

Methods for Creating Stored Procedures

The CREATE PROCEDURE Statement

Specify grouped stored procedures

Control whether an execution plan should be cached for the procedure

Encrypt the stored procedures content for security

Control execution behavior for a replication subscriber

additional syntax details concerning CREATE PROC, refer to the Transact-SQL

Providing a Stored Procedure with Context

Creating Temporary Stored Procedures

SELECT * from [pubs].[dbo].[authors]

Grouping, Caching, and Encrypting Stored Procedures