CCI – Computer Science Dept 655445336.

doc

Haramaya University
College of computing and Informatics

Computer Science Department

Comp 221: Database with SQL Server

Handout 7 – Stored Procedures, Transactions and SQL Programming

RECOMMENDED TEXTS:

• Ref A: “SQL Server 2000 – The Complete Reference”

Jeffrey R. Shapiro,
Osborne McGraw Hill

1 Overview
This handout describes SQL stored procedures and transactions. It also looks at some of the
T-SQL programming statements that can be used in stored procedures.

2 Stored Procedures

A SQL stored procedure is a saved piece of programming code, written in SQL, that can
accept passed parameters and be used to accomplish complex tasks. A stored procedure can
also return values to the calling program – which can be SQL or another application.

Transact-SQL provides programming statements that can be used to control the flow of the
program, and also provides functions (such as the date time functions we looked at in handout
6) for manipulating data values.

A stored procedure can be simply used just to save a select, update, insert or delete query as
well as to carry out more complex tasks. Because a procedure can accept parameters, they are
often used to save a select query when the search condition in the where clause is based on a
variable value e.g. ion the Pubs database, a query to get all the titles of a given type. The type
can be passed as a parameter.

Stored procedures are beneficial because they are pre-compiled – this means that the DBMS
builds an execution plan for the code when it is saved. Normally, the DBMS needs to build
an execution plan for a query when it is executed. Having a pre-compiled plan speeds up the
execution.

1.1 CREATE PROCEDURE

The Create Procedure statement is used to create a new stored procedure. The syntax is as
follows:

Page 1 of 9
CCI – Computer Science Dept 655445336.doc

CREATE PROC[EDURE] procedure_name

[ { @parameter data_type }[= default] [OUTPUT]
][,…n]

CREATE PROCEDURE spTitlesPubs

AS
Sql_statement […n]

Notes:
 The keyword PROC or PROCEDURE can be used
 A parameter is a value that can be passed into a procedure. Each parameter is given a
name, which must begin with the @ sign. A parameter can also be assigned a default
value by putting '= default_value' after the parameter, where default_value is the
desired default value. This means that the procedure can be executed without
supplying a value for the parameter, and the default value will be used instead. The
default value must be a constant value or NULL.
 The data type must be specified for each parameter.
 A parameter can also be specified as an OUTPUT. This means that the value of the
parameter can be set during the procedure, and it is available to the calling code.
 A procedure can have up to 2100 parameters.
 Sql_statement is any number of SQL statements to be run when the procedure is
executed. This can include executing one or more other stored procedures.

For example – the procedure 'byroyalty' is defined in the Pubs database. It is used to get a list
of Author IDs for authors who have a specified royalty percentage. The royalty percentage is
supplied as a parameter. Note that the GO statement is always the last line in a stored
procedure CREATE statement. It is placed at the end of the batch of SQL statements – this is
to tell the SQL Server to execute the statements in the procedure.

CREATE PROCEDURE byroyalty @percentage int

AS
select au_id from titleauthor
where titleauthor.royaltyper = @percentage

GO

The data type for a parameter should be consistent with the use of the parameter. For
example, the titleauthor.royaltyper column has data type int, so the parameter should also be
of int data type.

1.2 DROP PROCEDURE

A procedure can be dropped (deleted) from the database using this statement. For example:

DROP PROCEDURE sp_CreateNewTitle

If this is executed, it will drop the procedure named 'sp_CreateNewTitle'. If the procedure
does not exist in the database, a message indicating this will be returned.
If you wish to make a change to a procedure, it has to be dropped and then re-created with the
change in it.
Page 2 of 9
CCI – Computer Science Dept 655445336.doc

1.3 Executing a Stored Procedure

The EXECUTE statement is used to execute a stored procedure.
For example:

EXECUTE byroyalty 30

This will execute the byroyalty stored procedure, passing 30 as the value for the @percentage
parameter.
If the statement to execute a procedure is the first line in a batch, then the EXECUTE can be
omitted e.g.
byroyalty 30
but
select au_id, au_fname, au_lname from authors
byroyalty 30

- this will return an error because the execution of the procedure is the second line in the
batch. This should be:
select au_id, au_fname, au_lname from authors
execute byroyalty 30

1.4 Stored Procedures in Enterprise Manager

To see what stored procedures exist in a database, open the Enterprise Manager, navigate to
the database and then click the + next to the database name (e.g. pubs) and then click on
Stored Procedures.
There are a number of system stored procedures in every database – usually with a prefix of
'dt_' on the name. If any user procedures have been created in the database, they will also
appear here.

Modify a Stored Procedure

To see the definition for a stored procedure, double-click on it. This brings up the Stored
Procedure Properties dialog.
In this window, you can see the SQL that creates the procedure, including the Create
Procedure statement.
 To modify the SQL statements executed by the procedure, edit the SQL here.
 Click the Check Syntax button after making a change – if there are any errors in the
SQL, they will be reported when the button is clicked.
 Click Apply to apply the changes to the procedure – after applying, you can switch to
the Query Analyzer to execute it and make sure the results are as you expect.
 Click OK to apply the changes to the procedure and to exit from the dialog.

Create a New Stored Procedure

A new procedure can also be created in the Enterprise Manager, as follows.

 Right-click on the Stored Procedures item under the database name in the left pane
 Click 'New Stored Procedure…'
 This opens the Stored Procedure Properties dialog for a new procedure
 Enter the SQL statements for the procedure
Page 3 of 9
CCI – Computer Science Dept 655445336.doc

 Click the Check Syntax button – if there are syntax errors in the SQL, they will be
reported
 When finished writing the procedure, click OK to save it

Drop a Stored Procedure

To drop a stored procedure in Enterprise Manager, navigate to the Stored Procedure list in the
database.
 Click on the stored procedure to be dropped, and hit the Delete key or right-click and
choose Delete.
 This will bring up the Drop Objects dialog.
 To see if there are any objects dependent on the procedure and what objects it is
dependent on, click the Show Dependencies button.
 Make sure that only the procedure you want to drop is listed, then click Drop All to
drop it.
 If there are any objects that depend on the procedure e.g. another stored procedure
that references it, the procedure cannot be dropped until those objects are dropped.
SQL Server will warn if this is the case and will not drop the procedure.

3 An Overview of Transactions

A transaction is a sequence of operations performed as a single, logical unit of work. In a

DBMS, this is usually a series of data modifications.
For example, a transaction could be a series of database deletes and updates where all must
complete in order to complete a business process.
For example, taking the Departments/Employees database we have created during lab
exercises. A business process could be to delete a Department and assign all the Employees
that were assigned to the Department to be in another Department. In this example, both the
updates and the delete must succeed so that the whole operation succeeds. If both do not
succeed, the database may be left in an inconsistent state e.g. Employees that do not have a
Department if the update does not succeed.

1.5 ACID Properties of a Transaction

A logical unit of work must exhibit 4 properties to qualify as a transaction. These are known
as the ACID properties of a transaction – this is an acronym for Atomicity, Consistency,
Isolation and Durability. Each of these properties is explained below.

Atomicity – a transaction must be an atomic piece of work – this means that either all of its
data modifications are performed or none of them is performed. SQL Server provides
mechanisms to commit transactions that have completed successfully and to roll back
transactions when some part fails.

Consistency – when completed, a transaction must leave all data in a consistent state. In a
relational database, all rules must be applied to the transaction's modifications to maintain all
data integrity – the rules include referential integrity (foreign key constraints), nullability and
check constraints.
Page 4 of 9
CCI – Computer Science Dept 655445336.doc

Isolation – modifications made by concurrent transactions must be isolated from

modifications made by any other concurrent transactions. A concurrent transaction is one that
is occurring at the same time. If there are two transactions, A and B, occurring concurrently,
then transaction A should see the data in the state it was in before transaction B is carried out
or after transaction B was completed. Transaction A should not see the data in any
intermediate state (e.g. after one update but before another one). In practice, this means that a
DBMS provides mechanisms for a transaction to 'lock' the data it is working on – a lock
prevents other transactions from changing the data until the original transaction is completed.
SQL Server provides such mechanisms.

Durability – after a transaction has completed, its effects are permanent in the system. The
modifications should persist even in the event of a system failure. SQL Server provides a way
of logging all transactions so that if hardware or software fails, the transaction logs can be
used to restore the system to the state it was in at the point of failure.

SQL provides a series of statements for explicitly beginning and ending transactions.

Some DBMS applications, including SQL Server, also do implicit transactions for certain
SQL statements – this means that it is implied that a transaction has started when these
statements are executed. The statements include ALTER, CREATE, DELETE, DROP,
INSERT, SELECT and UPDATE.

The SQL statements to control transactions are as shown below.

Statement Description
BEGIN TRAN[SACTION] Marks the starting point of an explicit transaction
COMMIT TRAN[SACTION] Marks the end of an explicit or implicit transaction. An explicit transaction
is started with BEGIN TRANSACTION; an implicit transaction is started
by the DBMS when any of the statements indicated above are executed.
ROLLBACK TRAN[SACTION] Rolls back an implicit or explicit transaction to the starting point – the
starting point is the BEGIN TRANSACTION statement for an explicit
transaction or the first statement for an implicit transaction.
A roll back undoes or erases any data modifications made since the
transaction was started.
A transaction cannot be rolled back after a COMMIT TRANSACTION has
been executed.

1.6 Transaction Modes in SQL Server

SQL Server has 3 different modes for controlling transactions. The mode applies to an
individual connection to the server e.g. one instance of the Query Analyzer.

 Autocommit Transactions
This is the default mode. It means that every individual SQL statement is treated as a
transaction. If the execution of the statement succeeds, the transaction is committed, if it does
not, the transaction is rolled back.

 Implicit Transactions
In this mode, SQL Server automatically starts a new transaction when the previous one has
been committed or rolled back. The transaction must then be explicitly committed or rolled

Page 5 of 9
CCI – Computer Science Dept 655445336.doc

back using COMMIT TRANSACTION or ROLLBACK TRANSACTION. SQL Server

automatically starts a transaction when any of the following statements are executed:

ALTER TABLE INSERT

CREATE OPEN
DELETE REVOKE
DROP SELECT
FETCH TRUNCATE TABLE
GRANT UPDATE

The mode can be switched between Autocommit and Implicit Transactions using the SET
statement as follows (it can be set to ON or OFF):

SET IMPLICIT_TRANSACTIONS { ON | OFF}

This can also be set through the Query Analyzer:

o Choose Tools | Options
o Click on the Connection Properties tab
o There is a checkbox for 'Set Implicit Transactions' – check on to turn on Implicit
Transactions, uncheck to leave in Autocommit mode.

This mode is part of the SQL99 standard, so all RDBMS applications should provide it.

 Explicit Transactions
In this mode, transactions must be explicitly started and ended using BEGIN
TRANSACTION, COMMIT TRANSACTION and ROLLBACK TRANSACTION.
Explicit transactions can be used at any time i.e. if the Implicit_Transactions mode is on or
off.

1.7 Locking and Isolation Levels

As mentioned above, DBMS applications provide ways to lock database objects while they
are being used by a transaction. This ensures that only one transaction at a time can modify
data, thereby helping to achieve the Isolation property of a transaction.

A lock is access to an object that is granted to a particular transaction. The lock also restricts
access to the object from other transactions that are competing for the same resource.
If more than one transaction requires access to the data, they are queued up for the lock – so
when one transaction completes, the next one can then get access to the data. This is also
known as serialization.

Locks are expensive in terms of database resources – obtaining and setting locks add to the
time required to carry out transactions, and also cause other transactions to take longer as
they wait for locks to be released. However, if the competing transaction just wants to read
data, it is not necessary to completely block access to the object.

To minimise the overhead, different levels of locking can be assigned. In SQL Server, this
level is known as the Isolation Level.

Page 6 of 9
CCI – Computer Science Dept 655445336.doc

The isolation level can also be described as the level at which a transaction is prepared to
accept inconsistent data or the degree to which one transaction must be isolated from other
transactions.
A lower isolation level means that more transactions can occur at the same time – this
increases concurrency. But this is at the expense of correctness of the data – because some
transactions may gain access to data that is in the process of being changed by a transaction.

A higher isolation level ensures that data is always correct but the degree of concurrency can
be negatively affected – because access is granted to queued transactions only when data is
not being used by any transaction.

4 An example, with some SQL Programming

Returning to the example described in section 3 above, that of a business process to delete a
Department and assign all the Employees that were assigned to the Department to be in
another Department1.
We can now create a transaction to do this. One way is to use explicit transactions i.e. start a
transaction, carry out the data modifications and then commit the transaction.
Another way is to put the data modifications into a stored procedure.
When the stored procedure is executed using the Autocommit mode, it is a single SQL
statement and so it will be treated as a transaction. In fact, a stored procedure is a better way
of saving a set of data modifications such as these, as they are then saved in the database and
can easily be executed at any time.

In this example, we cannot delete the Department while there are still Employees associated
with it – this is because of the foreign key constraint between the two tables.

Let us assume that we are given the name for the new Department and the DepartmentID of
the department that is to be deleted. Then, the steps to carry out the complete process are as
follows (bearing in mind that the foreign key constraint between the Employees and
Departments tables will not allow for a Department to be deleted if there are associated
records in the Employees table):

 Create the new Department record

 Find out the DepartmentID for this record
 Update the Employees who are in the Department that is to be deleted, to change their
DepartmentID to the new one
 Delete the old Department

We need some T-SQL programming statements to help with this.

1.8 Declaring Variables

First, we will need to declare a variable to hold the DepartmentID of the new record. In T-
SQL a variable is declared using the DECLARE keyword; a variable name must begin with
the @ symbol and must be given a data type e.g. to declare a variable of type char(10):
1
Note – this is not a realistic situation, as it is unlikely that a Department would be deleted in reality. It is more
likely that the existing Department record would be updated with a new name, or a new Department added and
the old one kept in the system as historical data. However, this example serves to demonstrate a sequence of
steps that includes different data modifications.
Page 7 of 9
CCI – Computer Science Dept 655445336.doc

Declare @myVar char(10)

After it has been declared, a variable can be referenced in the batch of SQL

1.9 Getting the last ID Value

Then we need a way to find out the DepartmentID for the newly inserted Department record.
One way to do this is to select the maximum DepartmentID from the table e.g.

declare @myvar int

select @myvar = max(departmentid) from departments
print @myvar

The PRINT keyword prints the text following it out to the results pane.

Another way to get the ID value is to use the global variable @@identity – when this is
selected, it returns the last identity value generated by the previous insert.

1.10 Stored Procedure

So, a procedure to do this might be as follows:

create procedure spReplaceDepartment @DeptIDToDelete int

as
declare @NewDeptID int -- declares a variable named NewDeptID, type integer

-- insert the new department

insert into Departments (DepartmentName) values ('newdept2')
-- get the ID value for the new Department - @@identity returns the identity value for the last row inserted
-- (from a field that is an Identity field)
select @NewDeptID = @@Identity
-- update the Employees - for those who were in the old Department
update Employees set DepartmentID = @NewDeptID where DepartmentID = @DeptIDToDelete
-- now we can delete the old Department
delete from departments where DepartmentID = @DeptIDToDelete

GO

5 SQL Programming
This section is to provide you with a brief introduction to programming in T-SQL.
The section above introduced variables and showed how a variable may be used in T-SQL
code. The above example was within a stored procedure, however, a series of SQL statements
can be saved in a text file and treated simply as a batch that can be opened in the Query
Analyzer and executed at any time.
The details given here are for SQL Server's T-SQL only – they are not part of the SQL99
standard. However, other RDBMS applications provide their own programming languages
e.g .Oracle has PL/SQL.

The table below lists some elements of the control-of-flow language provided with T-SQL.

Keywords Description
BEGIN…END Marks the beginning and end of a block of SQL statements. Must be used to
delimit a 'statement_block', where one appears in the syntax for another construct
– see, for example, the IF/ELSE and WHILE/BREAK statements below.
Page 8 of 9
CCI – Computer Science Dept 655445336.doc

IF… ELSE Test for a condition, and if it is true, execute the first block of code; if not true,
IF Boolean_expression execute the block specified after the ELSE. If ELSE is not specified, flow
    { sql_statement | continues to the next statement. The condition is an expression that returns true or
statement_block } false.
[ ELSE See example below - note the use of BEGIN and END – this is necessary if more
    { sql_statement | than one line of code is to be executed when the condition is true or when it is
statement_block } ] false; also note that the condition can be the comparison of the result of a select
statement with a value:

IF (SELECT AVG(price) FROM titles WHERE type =

'mod_cook') < $15
BEGIN
PRINT 'The following titles are excellent mod_cook
books:'
PRINT ' '
SELECT SUBSTRING(title, 1, 35) AS Title
FROM titles
WHERE type = 'mod_cook'
END
ELSE
PRINT 'Average title price is more than $15.'
WHILE…BREAK This provides a While loop – the specified block of code is executed as long as the
WHILE Boolean_expression specified condition is true. The BREAK keyword causes the loop to exit –
    { sql_statement | statements after the END keyword are then executed. The CONTINUE keyword
statement_block } causes the loop to restart – any statements after continue will not be executed.
    [ BREAK ] When the loop completes i.e. when the condition is no longer true, the statements
    { sql_statement | after the END keyword are executed.
statement_block }
    [ CONTINUE ] USE pubs
GO
WHILE (SELECT AVG(price) FROM titles) < $30
BEGIN
UPDATE titles
SET price = price * 2
SELECT MAX(price) FROM titles
IF (SELECT MAX(price) FROM titles) > $50
BREAK
ELSE
CONTINUE
END
PRINT 'Too much for the market to bear'
RETURN [integer_expression] To exit, unconditionally, from a procedure, batch or statement block.
Any statements following the RETURN are not executed.
An integer value can optionally be returned – this is so that a caller can determine
if the procedure/batch/block was successful or not e.g. return 0 when successful, 1
if not. Generally, if not otherwise specified, a stored procedure will return 0 if it
executes successfully, and a non-zero value if some error occurs.
RETURN can be used to return a user-defined value.

Notes prepared by: Terri O'Sullivan, FBE Computer Science Department.

Page 9 of 9