Microsoft SQL Server 2008 R2 Unleashed- P94 pdf

Creating Custom Stored Procedure Templates To create a custom stored procedure template, right-click the Stored Procedure folder in the Template Explorer and select New.. You can double-

FIGURE 28.1 Using the Specify Values for Template Parameters dialog in SSMS

One thing you might notice about the stored procedure template is that it contains

template parameters for parameter names, procedure name, author name, create date, and

so on These template parameters are in the format <parameter, type, value>:

parameter_name is the name of the template parameter in the script

data_type is the optional data type of the template parameter

value is the default value to be used to replace every occurrence of the template

parameter in the script

You can auto substitute values for template parameters by selecting Query, Specify Values

for Template Parameters or by pressing Ctrl+Shift+M This brings up the dialog shown in

Figure 28.1

You enter the values for the template parameters in the Value column and then click OK

SSMS then substitutes any values you specified wherever the template parameter is used

within the template

An alternative way to create a stored procedure from a template is to use the Template

Explorer in SSMS You can open the Template Explorer by selecting View, Template

Explorer in SSMS or by pressing Ctrl+Alt+T The Template Explorer window appears in

SSMS, as shown in Figure 28.2

You can double-click the name of the stored procedure template you want to use or

right-click the desired template and then select Open SSMS opens a new query window,

popu-lated with the template code

FIGURE 28.2 Using the Template Explorer for creating stored procedures in SSMS

NOTE

It is also possible to edit the provided stored procedure templates available in the

Template Explorer by right-clicking them and selecting the Edit option You can then

cus-tomize the templates to include code fragments, comments, or structure that is more

to your preference and save the changes to the template file However, it is generally

recommended that you not modify the provided templates and instead create your own

custom templates

Creating Custom Stored Procedure Templates

To create a custom stored procedure template, right-click the Stored Procedure folder in

the Template Explorer and select New SSMS then creates an entry in the Template

Explorer, and you can specify the name for the template

To begin adding code to the template, right-click the template and select Edit This opens

a query window in which you can start entering the new template code Probably the best

way to get started is to copy the template code from one of the templates provided with

SQL Server 2008 and then modify it as you desire You then select File, Save to save the

template code to the file

Listing 28.3 shows an example of a new stored procedure template

LISTING 28.3 An Example of Custom Stored Procedure Template

=============================================

Create basic stored procedure template

=============================================

Drop stored procedure if it already exists

IF EXISTS (

SELECT *

FROM sys.procedures

WHERE schema_id = schema_id(‘dbo’)

AND name = N’<Proc_Name, sysname, myproc>’

)

DROP PROCEDURE <Schema_Name, sysname, dbo>.<Proc_Name, sysname, myproc>

GO

=============================================

Author: <Author,,Name>

Create date: <Create Date,,>

Description: <Description,,>

=============================================

CREATE PROCEDURE <Schema_Name, sysname, dbo>.<Proc_Name, sysname, myproc>

— Add the parameters for the stored procedure here

<@param1, sysname, @p1> <param1_type, , int> = <param1_default, , 0>,

<@param2, sysname, @p2> <param2_type, , int> = <param2_default, , 0>,

<@param3, sysname, @p3> <param3_type, , int> OUTPUT

AS

BEGIN

SET NOCOUNT ON added to prevent extra result sets from

interfering with SELECT statements

SET NOCOUNT ON;

DECLARE @trancnt int

SELECT @trancnt = @@TRANCOUNT

if @trancnt = 0

BEGIN TRAN <Proc_Name, sysname, myproc>

else

SAVE TRAN <Proc_Name, sysname, myproc>

/* Insert processing code here */

if (@@error != 0) check for error condition

begin

rollback to savepoint, or begin tran

rollback tran <Proc_Name, sysname, myproc>

return error code indicating rollback

return -101

end

/* Insert more processing here if required */

set value of output parameter

set <@param3,sysname, @p3> = <@param1,sysname, @p1> + <@param2,sysname, @p2>

if @trancnt = 0 this proc issued begin tran

commit tran, decrement @@trancount to 0

commit tran <Proc_Name, sysname, myproc>

commit not required with save tran

return 0 /* successful return */

END

GO

— =============================================

— Example to execute the stored procedure

— =============================================

DECLARE <@output_variable, sysname, @p3_output> <output_datatype, , int>

EXECUTE <Schema_name, sysname, dbo>.<Proc_name, sysname, myproc>

<@param1, sysname, @p1> = <param1_value, , 1>,

<@param2, sysname, @p2> = <param2_value, , 1>,

<@param3, sysname, @p3> = <@output_variable, sysname, @p3_output> OUTPUT

SELECT <@output_variable, sysname, @p3_output>

GO

After you define a custom stored procedure template, you can use it as you would use the

built-in templates You can double-click it or right-click and select Open, and SSMS opens

a new query window with a new stored procedure creation script based on the custom

template If you use the default values for the template parameters, after the parameter

substitution, the CREATE PROCEDURE script looks like the one in Listing 28.4

LISTING 28.4 An Example of a CREATE PROCEDURE Script Generated from the Custom

Stored Procedure Template

=============================================

Create basic stored procedure template

=============================================

Drop stored procedure if it already exists

IF EXISTS (

SELECT *

FROM sys.procedures

WHERE schema_id = schema_id(‘dbo’)

AND name = N’myproc’

)

DROP PROCEDURE dbo.myproc

GO

=============================================

Author: Name

Create date:

Description:

=============================================

CREATE PROCEDURE dbo.myproc

— Add the parameters for the stored procedure here

@p1 int = 0,

@p2 int = 0,

@p3 int OUTPUT

AS

BEGIN

SET NOCOUNT ON added to prevent extra result sets from

interfering with SELECT statements

SET NOCOUNT ON;

DECLARE @trancnt int

SELECT @trancnt = @@TRANCOUNT

if @trancnt = 0

BEGIN TRAN myproc

else

SAVE TRAN myproc

/* Insert processing code here */

if (@@error != 0) check for error condition

begin

rollback to savepoint, or begin tran

rollback tran myproc

return error code indicating rollback

return -101

end

/* Insert more processing here if required */

set value of output parameter

set @p3 = @p1 + @p2

if @trancnt = 0 this proc issued begin tran

commit tran, decrement @@trancount to 0

commit tran myproc

commit not required with save tran

return 0 /* successful return */

END

GO

=============================================

Example to execute the stored procedure

=============================================

DECLARE @p3_output int

EXECUTE dbo.myproc

@p1 = 1,

@p2 = 1,

@p3 = @p3_output OUTPUT

SELECT @p3_output

GO

Temporary Stored Procedures

SQL Server enables you to create private and global temporary stored procedures

Temporary stored procedures are analogous to temporary tables in that they can be

created with the # and ## prefixes added to the procedure name The # prefix denotes a

local temporary stored procedure; ## denotes a global temporary stored procedure A local

temporary stored procedure can be executed only by the connection that created it, and

the procedure is automatically deleted when the connection is closed A global temporary

stored procedure can be accessed by multiple connections and exists until the connection

used by the user who created the procedure is closed and any currently executing versions

of the procedure by any other connections are completed

If a stored procedure not prefixed with # or ## is created directly in the tempdb database,

the stored procedure exists until SQL Server is shut down Procedures created directly in

tempdb continue to exist even after the creating connection is terminated

Temporary stored procedures are provided for backward compatibility with earlier versions

of SQL Server that did not support the reuse of execution plans for T-SQL statements or

batches Applications connecting to SQL Server 2000 and higher should use the

sp_executesql system stored procedure to execute dynamic SQL statements instead of

creating temporary stored procedures

TIP

It is strongly recommended that sp_executesql be used instead of temporary stored

procedures Excessive use of temporary stored procedures can lead to locking

con-tention on the system tables in tempdb, which can adversely affect overall system

per-formance For more information on using sp_executesql, see Chapter 44, "Advanced

Stored Procedure Programming and Optimization."

Executing Stored Procedures

To execute a stored procedure, you simply invoke it by using its name (the same way you

probably have already executed system stored procedures, such as sp_help) If the

execu-tion of the stored procedure isn’t the first statement in a batch, you need to precede the

procedure name with the EXEC keyword Following is the basic syntax for executing stored

procedures:

[EXEC[UTE]] [@status =] [schema].procedure_name[; number]

[[@param_name =] expression [output][, ]]

[WITH RECOMPILE]

NOTE

The reason you need the EXEC keyword when invoking a stored procedure in a batch or

other stored procedure is quite simple SQL Server parses the commands sent to it in

a batch by searching for keywords Stored procedure names aren’t keywords If SQL

Server finds a procedure name among the SQL statements, chances are that SQL

Server will return an error message because it tries to treat it as part of the preceding

command Sometimes the execution is successful, but SQL Server doesn’t execute

what you want Consider this example:

SELECT * FROM titles

sp_help

The SELECT statement runs fine, but the procedure is not executed The reason is

that sp_help ends up being used as a table alias for the titles table in the

SELECT statement

However, if you precede the procedure name with EXEC, like this, you get the

expected behavior:

SELECT * FROM titles

EXEC sp_help

Why don’t you have to put EXEC in front of the procedure name if the procedure is the

first statement in a batch? If SQL Server doesn’t recognize the first string in a batch, it

simply assumes that it is a name of a stored procedure For example, execute the

following string and notice the error message:

Dsfdskgkghk

go

Msg 2812, Level 16, State 62, Line 1

Could not find stored procedure ‘Dsfdskgkghk’

As good programming practice, it is best to always precede stored procedures with the

EXEC keyword This way, it will always work as expected, whether or not it’s the first

statement in a batch

Executing Procedures in SSMS

To execute a stored procedure in SSMS, open the object tree for the database, open the

Programmability folder, and open the Stored Procedures folder Then right-click the

stored procedure, and from the context menu, choose Execute Stored Procedure SSMS

then presents you with the Execute Procedure dialog, as shown in Figure 28.3 In this

window, you can enter values for any parameters contained in the stored procedure If you

want to pass a NULL value to a parameter, you need to be sure to place a check mark in the

Pass Null Value check box for that parameter

After you specify values for all the parameters, SSMS opens a new query window with the

generated execute statement and automatically executes it It displays any results in the

Results window If the stored procedure contains output parameters, SSMS generates local

variables for the output parameters and uses a SELECT statement to display the values

returned to the output parameters Listing 28.5 shows an example of the execute script

and its results for the procedure invoked in Figure 28.3 (this procedure is the one

gener-ated from the custom procedure template, as shown in Listing 28.4)

LISTING 28.5 A Procedure Execution Script Generated by SSMS

USE [bigpubs2008]

GO

DECLARE @return_value int,

@p3 int

EXEC @return_value = [dbo].[myproc]

@p1 = 100,

@p2 = 200,

@p3 = @p3 OUTPUT

FIGURE 28.3 Using the Execute Procedure dialog in SSMS

SELECT @p3 as N’@p3’

SELECT ‘Return Value’ = @return_value

GO

@p3

-300

Return Value

-0

Execution Context and the EXECUTE AS Clause

Normally, stored procedures execute within the security context of the current user The

user must have execute permission on the procedure and if the objects referenced within

the stored procedure are not owned by the user who created the stored procedure, the

current user must also have the necessary permissions granted on the referenced objects

The current user does not inherit the permissions of the procedure creator The only

exception to this occurs when the objects referenced by a stored procedure are owned by

the same user who created the stored procedure In this case, permissions on the

refer-enced objects in the stored procedure are dependent on the ownership chain that exists

between the calling procedure and referenced objects For example, if the creator of a

stored procedure also owns the table that it references, the user executing the stored

procedure inherits the rights on the referenced table from the owner within the context of

the stored procedure, without having to be granted explicit rights on the table by the

table owner

However, there are limitations to using ownership chaining alone for inheriting access

permissions:

The rights inherited by ownership chaining apply only to DML statements: SELECT,

INSERT, UPDATE, and DELETE

The owners of the calling and called objects must be the same

The rights inherited by ownership chaining do not apply to dynamic queries inside

the stored procedure

In SQL Server 2008, you can implicitly define the execution context of functions (except

inline table-valued functions), stored procedures, and triggers by specifying the EXECUTE

AS clause The EXECUTE AS clause allows you to go beyond ownership chaining to specify

the security context under which a stored procedure will execute and what access rights

the user will have on the referenced objects The EXECUTE AS clause allows you to specify

explicitly the security context under which the stored procedure will execute In other

words, it allows you to specify which user account SQL Server should use to validate

permissions on the database objects referenced by the stored procedure The user

execut-ing the stored procedure, in effect, impersonates the user specified in the EXECUTE AS

clause within the context of the execution of the stored procedure

The EXECUTE AS clause can be specified when the stored procedure is created to set the

default security context for all users when executing the stored procedure Alternatively,

the EXECUTE AS clause can be specified explicitly within the stored procedure code or

within each individual user session When specified in a user session, the security context

switches to that specified until the connection is closed, a REVERT statement is run, or

another EXECUTE AS statement is run

The syntax of the EXECUTE AS clause for stored procedures is as follows:

{ EXEC | EXECUTE } AS { CALLER | SELF | OWNER | ‘user_name’ }

You can specify the following security context options when using the EXECUTE AS clause:

CALLER —This option specifies that the statements inside the stored procedure are

executed in the context of the caller of the module (that is, the current user) The

user executing the stored procedure must have execute permission on the stored

procedure and also permissions on any database objects that are referenced by the

stored procedure that are not owned by the procedure creator CALLER is the default

behavior for all stored procedures, and it is the same as SQL Server 2000 behavior