Module 8: Implementing Stored Procedures

Transcription

1 Module 8: Implementing Stored Procedures Table of Contents Module Overview 8-1 Lesson 1: Implementing Stored Procedures 8-2 Lesson 2: Creating Parameterized Stored Procedures 8-10 Lesson 3: Working With Execution Plans 8-19 Lesson 4: Handling Errors 8-28 Lab: Implementing Stored Procedures 8-36

2 Information in this document, including URL and other Internet Web site references, is subject to change without notice. Unless otherwise noted, the example companies, organizations, products, domain names, e- mail addresses, logos, people, places, and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, address, logo, person, place, or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation. The names of manufacturers, products, or URLs are provided for informational purposes only and Microsoft makes no representations and warranties, either expressed, implied, or statutory, regarding these manufacturers or the use of the products with any Microsoft technologies. The inclusion of a manufacturer or product does not imply endorsement of Microsoft of the manufacturer or product. Links are provided to third party sites. Such sites are not under the control of Microsoft and Microsoft is not responsible for the contents of any linked site or any link contained in a linked site, or any changes or updates to such sites. Microsoft is not responsible for webcasting or any other form of transmission received from any linked site. Microsoft is providing these links to you only as a convenience, and the inclusion of any link does not imply endorsement of Microsoft of the site or the products contained therein. Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property Microsoft Corporation. All rights reserved. Microsoft, BizTalk, Internet Explorer, Jscript, MSDN, Outlook, PowerPoint, SQL Server, Visual Basic, Visual C#, Visual C++, Visual FoxPro, Visual Studio, Windows and Windows Server are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. The names of actual companies and products mentioned herein may be the trademarks of their respective owners. Version 1.1

3 Module 8: Implementing Stored Procedures 8-1 Module Overview As a database developer, you might be expected to design and implement logic within the database to enforce business rules or data consistency by using stored procedures. Alternatively, you might be responsible for modifying and maintaining existing modules written by other developers. In this module, you will learn how to create stored procedures and how to view and understand execution plans. You will also learn how to implement structured error handling. Objectives After completing this module, you will be able to: Implement stored procedures. Create parameterized stored procedures. Work with execution plans. Handle errors in stored procedures.

4 8-2 Module 8: Implementing Stored Procedures Lesson 1: Implementing Stored Procedures A stored procedure is a group of Transact-SQL statements compiled into a single execution plan. Stored procedures can assist you in achieving a consistent implementation of logic across applications. This lesson describes what stored procedures are and what benefits they can bring to your database applications. You will also learn how to alter and remove existing stored procedures. Objectives After completing this lesson, you will be able to: Describe stored procedures. Create stored procedures. Describe the guidelines for creating stored procedures. Alter and drop stored procedures.

5 Module 8: Implementing Stored Procedures 8-3 What Is a Stored Procedure? A stored procedure is a named collection of Transact-SQL statements that is stored on the server within the database itself. Stored procedures are a method of encapsulating repetitive tasks; they support user-declared variables, conditional execution, and other powerful programming features. Stored procedures in Microsoft SQL Server are similar to procedures in other programming languages, in that they can: Contain statements that perform operations in the database, including the ability to call other stored procedures. Accept input parameters. Return a status value to a calling stored procedure or batch to indicate success or failure. Return multiple values to the calling stored procedure or client application in the form of output parameters. Advantages of Stored Procedures Stored procedures offer numerous advantages over executing ad hoc Transact-SQL queries. They can: Encapsulate business functionality and create reusable application logic. Business rules or policies encapsulated in stored procedures can be changed in a single location. All clients can use the same stored procedures to ensure consistent data access and modification.

6 8-4 Module 8: Implementing Stored Procedures Shield users from exposure to the details of the tables in the database. If a set of stored procedures supports all the business functions that users need to perform, users never need to access the tables directly. Provide security mechanisms. Users can be granted permission to execute a stored procedure even if they do not have permission to access the tables or views to which the stored procedure refers. Improve performance. Stored procedures implement many tasks as a series of Transact-SQL statements. Conditional logic can be applied to the results of the first Transact-SQL statements to determine which subsequent Transact-SQL statements are executed. All these Transact-SQL statements and conditional logic become part of a single execution plan on the server. Reduce network traffic. Rather than send hundreds of Transact-SQL statements over the network, users can perform a complex operation by sending a single statement, which reduces the number of requests that pass between client and server Reduce vulnerability to SQL injection attacks. Using explicitly defined parameters in SQL code reduces the possibility that a hacker could submit embedded SQL statements in the parameter values.

7 Module 8: Implementing Stored Procedures 8-5 Syntax for Creating Stored Procedures You create stored procedures by using the CREATE PROCEDURE statement. Stored procedures can be created only in the current database, except for temporary stored procedures, which are always created in the tempdb database. Creating a stored procedure is similar to creating a view. First, write and test the Transact-SQL statements that you want to include in the stored procedure. Then, if you receive the results that you expect, create the stored procedure. Partial Syntax for Creating a Stored Procedure The CREATE PROCEDURE statement contains many possible options, as shown in the following partial syntax. CREATE { PROC PROCEDURE } [schema_name.] procedure_name [ [ type_schema_name. ] data_type } [ VARYING ] [ = default ] [ [ OUT [ PUT ] ] [,...n ] [ WITH <procedure_option> [,...n ] AS sql_statement [;][...n ] <procedure_option> ::= [ ENCRYPTION ] [ RECOMPILE ] [ EXECUTE_AS_Clause ] For more information about the complete CREATE PROCEDURE syntax, see CREATE PROCEDURE (Transact-SQL) in SQL Server Books Online. Example of Creating a Simple Stored Procedure The following example shows how you can create a simple stored procedure that returns a rowset of all products that take more than one day to manufacture.

8 8-6 Module 8: Implementing Stored Procedures CREATE PROC Production.LongLeadProducts AS SELECT Name, ProductNumber FROM Production.Product WHERE DaysToManufacture >= 1 GO The previous example creates a procedure named LongLeadProducts within the Production schema. A GO command is included to emphasize the fact that CREATE PROCEDURE statements must be declared within a single batch. Example of Calling a Stored Procedure The following example shows how to call the LongLeadProducts stored procedure. EXEC Production.LongLeadProducts

9 Module 8: Implementing Stored Procedures 8-7 Guidelines for Creating Stored Procedures Consider the following guidelines when you create stored procedures: Qualify object names referenced by a stored procedure with the appropriate schema name. This ensures that tables, views, or other objects from different schemas are accessible within the stored procedure. If the referenced object name is not qualified, the stored procedure s schema is searched by default. Design each stored procedure to accomplish a single task. Create, test, and troubleshoot your stored procedure on the server, and then test it from the client. Avoid using the sp_ prefix when you name local stored procedures, to easily distinguish system stored procedures. Another reason to avoid the sp_ prefix for stored procedures in a local database is to avoid unnecessary searches of the master database. When a stored procedure with a name beginning with sp_ is called, SQL Server searches the master database before it searches the local database. Use the same connection settings for all stored procedures. SQL Server saves the settings of both SET QUOTED_IDENTIFIER and SET ANSI_NULLS options when a stored procedure is created or altered. These original settings are used when the stored procedure is executed. Therefore, any client session settings for these SET options are ignored during stored procedure execution. Minimize the use of temporary stored procedures to avoid contention on the system tables in tempdb, a situation that can adversely affect performance.

10 8-8 Module 8: Implementing Stored Procedures Syntax for Altering and Dropping Stored Procedures You may often need to modify stored procedures in response to requests from users or changes in the underlying table definitions. To modify an existing stored procedure and retain permission assignments, use the ALTER PROCEDURE statement. SQL Server replaces the previous definition of the stored procedure when it is altered by using ALTER PROCEDURE. Consider the following facts when you use the ALTER PROCEDURE statement If you want to modify a stored procedure that was created by using an option, such as the WITH ENCRYPTION option, you must include the option in the ALTER PROCEDURE statement to retain the functionality that the option provides. ALTER PROCEDURE changes only a single procedure. If your procedure calls other stored procedures, the nested stored procedures are not affected. Example of Altering a Stored Procedure The following example modifies the LongLeadProducts stored procedure to select an extra column and to sort the result set by using an ORDER BY clause. ALTER PROC Production.LongLeadProducts AS SELECT Name, ProductNumber, DaysToManufacture FROM Production.Product WHERE DaysToManufacture >= 1 ORDER BY DaysToManufacture DESC, Name GO

11 Module 8: Implementing Stored Procedures 8-9 Removing Stored Procedures Use the DROP PROCEDURE statement to remove user-defined stored procedures from the current database. Before you drop a stored procedure, execute the sp_depends stored procedure to determine whether objects depend on the stored procedure, as shown in the following example. EXEC = N'Production.LongLeadProducts' The following example drops the LongLeadProducts stored procedure. DROP PROC Production.LongLeadProducts

12 8-10 Module 8: Implementing Stored Procedures Lesson 2: Creating Parameterized Stored Procedures Stored procedures are more flexible when you include parameters as part of the procedure definition, because you can create more generic application logic. In this lesson, you will learn how to include input and output parameters and how to use return values within stored procedures. Objectives After completing this lesson, you will be able to: Use input parameters. Use output parameters and return values.

13 Module 8: Implementing Stored Procedures 8-11 Input Parameters A stored procedure communicates with the program that calls the procedure through a list of up to 2,100 parameters. Input parameters allow information to be passed into a stored procedure; these values can then be used as local variables within the procedure. Guidelines for Using Input Parameters To define a stored procedure that accepts input parameters, you declare one or more variables as parameters in the CREATE PROCEDURE statement. Consider the following guidelines when using input parameters: Provide default values for a parameter where appropriate. If a default is defined, a user can execute the stored procedure without specifying a value for that parameter. Validate all incoming parameter values at the beginning of a stored procedure to trap missing and invalid values early. This might include checking whether the parameter is NULL. Example of Using Input Parameters The following example adds parameter to the LongLeadProducts stored procedure. This allows the WHERE clause to be more flexible than previously shown by allowing the calling application to define what length of lead time is considered appropriate. ALTER PROC int = 1 -- default value AS IF (@MinimumLength < 0) -- validate BEGIN RAISERROR('Invalid lead time.', 14, 1)

14 8-12 Module 8: Implementing Stored Procedures RETURN END SELECT Name, ProductNumber, DaysToManufacture FROM Production.Product WHERE DaysToManufacture ORDER BY DaysToManufacture DESC, Name The stored procedure defines a default parameter value of 1 so that calling applications can execute the procedure without specifying an argument. If a value is passed it is validated to ensure that the value is appropriate for the purpose of the SELECT statement. If the value is less than zero, an error is raised, and the stored procedure returns immediately without executing the SELECT statement. Calling Parameterized Stored Procedures You can set the value of a parameter by passing the value to the stored procedure by either parameter name or position. You should not mix the different formats when you supply values. Specifying a parameter in an EXECUTE statement in the = value is referred to as passing by parameter name. When you pass values by parameter name, the parameter values can be specified in any order, and you can omit parameters that allow null values or that have a default. The following example calls the LongLeadProducts stored procedure and specifies the parameter name. EXEC Passing only values (without reference to the parameter names to which they are being passed) is referred to as passing values by position. When you specify only a value, the parameter values must be listed in the order in which they are defined in the CREATE PROCEDURE statement. When you pass values by position, you can omit parameters where defaults exist, but you cannot interrupt the sequence. For example, if a stored procedure has five parameters, you can omit both the fourth and fifth parameters, but you cannot omit the fourth parameter and specify the fifth. The following example calls the LongLeadProducts stored procedure and specifies the parameter by using the position only. EXEC Production.LongLeadProducts 4 Using the Default Values of a Parameter The default value of a parameter, if defined for the parameter in the stored procedure, is used when: No value for the parameter is specified when the stored procedure is executed. The DEFAULT keyword is specified as the value for the parameter.

15 Module 8: Implementing Stored Procedures 8-13 Output Parameters and Return Values Stored procedures can return information to the calling stored procedure or client by using both output parameters and a return value. Output Parameter Characteristics Output parameters allow any changes to the parameter that result from the execution of the stored procedure to be retained, even after the stored procedure completes execution. To use an output parameter within Transact-SQL, you must specify the OUTPUT keyword in both the CREATE PROCEDURE and the EXECUTE statements. If the OUTPUT keyword is omitted when the stored procedure is executed, the stored procedure still executes, but does not return the modified value. In most client programming languages, such as Microsoft Visual C#, parameter direction defaults to input, so you must indicate the parameter s direction in the client. Example of Using Output Parameters The following example creates a stored procedure that inserts a new department into the HumanResources.Department table of the AdventureWorks database. CREATE PROC smallint OUTPUT AS INSERT INTO HumanResources.Department (Name, GroupName) VALUES = SCOPE_IDENTITY()

16 8-14 Module 8: Implementing Stored Procedures output parameter stores the identity of the new record by calling the SCOPE_IDENTITY function so that a calling application can immediately access the automatically generated ID number The following example shows how the calling application can store the results of the stored procedure execution using the local int EXEC AddDepartment 'Refunds', OUTPUT Return Values You can also return information from a stored procedure by using the RETURN statement. This method is more limiting than using output parameters because it returns only a single integer value. The RETURN statement is most commonly used to return a status result or an error code from a procedure. The following example alters the AddDepartment stored procedure to return a success or failure value. ALTER PROC smallint OUTPUT AS IF ((@Name = '') OR (@GroupName = '')) RETURN -1 INSERT INTO HumanResources.Department (Name, GroupName) VALUES = SCOPE_IDENTITY() RETURN 0 If an empty string is passed to the procedure for either parameter, a -1 value is returned to indicate failure. If the INSERT statement succeeds, a 0 value is returned to indicate success. The following example shows how the calling application can store the return value of the stored procedure execution by using the local int = AddDepartment 'Refunds', OUTPUT IF (@result = 0) ELSE SELECT 'Error during insert' Note: SQL Server automatically returns a 0 from stored procedures if you do not specify your own RETURN value.

17 Module 8: Implementing Stored Procedures 8-15 Practice: Creating a Parameterized Stored Procedure The purpose of this practice is to enable you to implement stored procedures. You will practice creating stored procedures that accept input and output parameters; you will also practice creating stored procedures that return values. Finally, you will practice dropping a stored procedure. Objectives In this practice, you will: Create a simple stored procedure. Create a stored procedure that accepts an input parameter. Create a stored procedure that accepts an output parameter and returns values. Drop a stored procedure. Instructions Start the 2779B-MIA-SQL-08 virtual machine. Log on to the virtual machine with the user name Student and the password Pa$$w0rd. Create a simple stored procedure 1. Click Start, point to All Programs, point to Microsoft SQL Server 2005, and then click SQL Server Management Studio. 2. In the Connect to Server dialog box, specify the values in the following table, and then click Connect.

18 8-16 Module 8: Implementing Stored Procedures Property Server type Server name Authentication Value Database Engine MIAMI 3. On the File menu, point to Open, and then click File. Windows Authentication 4. In the Open File dialog box, navigate to the D:\Practices folder, click the StoredProcedures.sql query file, and then click Open. 5. In the Connect to Database Engine dialog box, specify the values in the following table, and then click Connect. Property Server name Authentication Value MIAMI Windows Authentication 6. Examine the code under the comment Get reviews for all products, select the code, and then click Execute. 7. Review the query output and confirm that the command completed successfully. 8. Select the query under the comment Test stored procedure, and then on the toolbar, click Execute. 9. Review the query results. Create a stored procedure that accepts an input parameter 1. Select the ALTER PROCEDURE statement under the comment Alter procedure to get specific product review, and then on the toolbar, click Execute. 2. Review the query output and confirm that the command completed successfully. 3. Select the query under the comment Test procedure with parameter, and then on the toolbar, click Execute. 4. Review the query results. Notice that the first EXECUTE statement produced the correct results but that the second EXECUTE statement failed because the parameter was not passed to the procedure and the parameter does not have a default value within the procedure. 5. Select the ALTER PROCEDURE statement under the comment Alter procedure to get specific product review or all reviews, and then on the toolbar, click Execute. 6. Review the query output and confirm that the command completed successfully. 7. Select the query under the comment Test procedure with parameter and default, and then on the toolbar, click Execute.

19 Module 8: Implementing Stored Procedures Review the query results. Notice that the first EXECUTE statement produces results for the specified product and that the second EXECUTE statement produces results for all products. Create a stored procedure that accepts an output parameter and returns values 1. Select the ALTER PROCEDURE statement under the comment Alter procedure to output number of reviews and check product exists, and then on the toolbar, click Execute. 2. Review the query output and confirm that the command completed successfully. 3. Select the queries between the comment Test output and return values and the GO statement, and on the toolbar, click Execute. 4. Review the query results. Notice that the results are displayed correctly, followed by the number of reviews from the output parameter. 5. Modify the EXECUTE statement by removing the OUTPUT keyword. 6. Reselect the queries between the comment Test output and return values and the GO statement, and then on the toolbar, click Execute 7. Review the query results. Notice that the results are displayed correctly but that the number of reviews returns NULL because the OUTPUT keyword was removed. 8. Modify the EXECUTE statement by putting the OUTPUT keyword back and changing the input parameter from 937 to DEFAULT. 9. Reselect the queries between the comment Test output and return values and the GO statement, and then on the toolbar, click Execute. 10. Review the query results. Notice that all reviews are now returned and that the number of reviews has increased. 11. Modify the EXECUTE statement by changing the input parameter from DEFAULT to Reselect the queries between the comment Test output and return values and the GO statement, and then on the toolbar, click Execute. 13. Review the query results. Notice that no reviews are returned and that the message ProductID does not exist is displayed because an invalid product ID was used. Drop a stored procedure 1. Select the DROP PROCEDURE statement under the comment Drop the procedure, and then on the toolbar, click Execute. 2. Review the query output and confirm that the command completed successfully.

20 8-18 Module 8: Implementing Stored Procedures 3. Close SQL Server Management Studio without saving any changes to the file. After you complete the practice, you must shut down the 2779B-MIA-SQL-08 virtual machine and discard any changes. Important: If the Close dialog box appears, ensure that Turn off and delete changes is selected, and then click OK.

21 Module 8: Implementing Stored Procedures 8-19 Lesson 3: Working With Execution Plans This lesson introduces the Microsoft SQL Server 2005 execution plans. An understanding of the execution plan that SQL Server uses to execute a query enables you to further optimize your queries and potentially improve performance. Objectives After completing this lesson, you will be able to: Describe an execution plan. View an execution plan. Explain how execution plans are cached. Describe the query compilation process. Recompile a stored procedure.

22 8-20 Module 8: Implementing Stored Procedures What Is an Execution Plan? A query execution plan shows how SQL Server navigates the tables and views, and how it uses indexes to execute a query. You can view the execution plan for how a query was run (the actual plan), or the way that SQL Server will run the query (the estimated plan). The actual and estimated plans may differ slightly because SQL Server takes into account other operations running on the server in the actual execution plan. The results will be similar in most cases. Performance and Optimization The execution plan does not contain any execution context information and no more than one or two copies are stored in memory: one for serial execution, and the other for parallel execution. You can investigate the details of a query execution plan to look for possible performance problems, such as table or index scans, bookmark lookups, filtering, or sorting.

23 Module 8: Implementing Stored Procedures 8-21 Viewing an Execution Plan You can view execution plans in SQL Server 2005 by using SQL Server Management Studio, by using Transact-SQL SET statement options, or by using SQL Server Profiler event classes. SQL Server Profiler event classes are out of scope for this course. For more information about SQL Server Profiler event classes, see Displaying Execution Plans by Using SQL Server Profiler Event Classes in SQL Server Books Online. SQL Server Management Studio You can view the estimated and actual execution plans for a query graphically by using SQL Server Management Studio. You can also save execution plans and view saved execution plans by using SQL Server Management Studio. Use the following procedure to view an execution plan graphically by using SQL Server Management Studio: 1. Open or type a Transact-SQL script in the Management Studio query editor. 2. Click either the Display Estimated Execution Plan button or the Include Actual Execution Plan button on the query editor toolbar. 3. After you click the Display Estimated Execution Plan button, the query is parsed and the estimated execution plan is generated. If you click the Include Actual Execution Plan button, you must execute the query to generate the execution plan. 4. Click the Execution plan tab to see the graphical representation of the execution plan. For more information, see Displaying Graphical Execution Plans (SQL Server Management Studio in SQL Server Books Online.

24 8-22 Module 8: Implementing Stored Procedures Transact-SQL SET Statement Options You can use the Transact-SQL SET statement options to generate an estimated or actual execution plan. When you use the Transact-SQL SET statement options you can produce execution plans in XML format or plain text. The following SET statement options enable you to generate the execution plan for a query: SET SHOWPLAN_XML ON. This statement configures SQL Server to generate an estimated execution plan in XML format. SET SHOWPLAN_TEXT ON. This statement configures SQL Server to generate an estimated execution plan in text format. SET STATISTICS XML ON. This statement configures SQL Server to generate an actual execution plan, including execution information for each statement, as a set of well-formed XML documents. SET STATISTICS PROFILE ON. This statement configures SQL Server to generate an actual execution plan, including execution information for each statement, in text form. Note: In a future version of SQL Server the SHOWPLAN_TEXT and STATISTICS PROFILE options for the SET statement will be deprecated in favor of their XML equivalents. For more information, see Displaying Execution Plans by Using the Showplan SET Options (Transact-SQL) in SQL Server Books Online.

25 Module 8: Implementing Stored Procedures 8-23 Execution Plan Caching SQL Server 2005 uses a single pool of memory to store execution plans and data buffers. The allocation of this pool between data buffers and execution plans is dynamic and varies depending on the state of the server. The part of this memory pool that is used to store execution plans is called the procedure cache. Execution Plan Caching An execution plan consists of the query plan and the execution context. The execution context includes information such as parameter values. When a query is executed in SQL Server 2005, the relational engine first checks the procedure cache to check for an existing execution plan that matches the query. If an execution plan is found in the procedure cache, it is reused, which saves the additional overhead of recompiling the query. If there is no matching execution plan in the procedure cache, then SQL Server generates a new execution plan for the query. SQL Server removes old and unused execution plans from the procedure cache only when the space is required. Each execution plan has a cost factor associated with it that indicates the relative cost to compile the associated query. There is also an age field that indicates how recently the execution plan was used. SQL Server uses a combination of the age and cost fields to determine which execution plan should be removed when SQL Server requires additional space in the procedure cache. Factors That Affect Whether a Query Is Cached When SQL Server 2005 compiles a query, there are a number of factors that affect whether the query is cached. SQL Server 2005 marks each statement in the query as cacheable, fixed-cost on reuse, cache even though zero-cost, not cacheable, or not cacheable because of sensitive information. If at least one of the statements in the query

26 8-24 Module 8: Implementing Stored Procedures is marked as cacheable, then the query is cached, unless any one statement in the query contains sensitive information, then that statement is marked as not cacheable because of sensitive information. This causes the whole query to be marked not cacheable. Statements that include sensitive information include: CREATE/ALTER APP ROLE, CREATE/ALTER LOGIN, and ALTER DATABASE. DDL statements are generally infrequent and require a recompile and so these are also marked not cacheable, although an exception is made for temporary table CREATE and DROP statements, which would benefit from caching. The list of exceptions includes: CREATE/DROP TABLE, DROP PROCEDURE, and UPDATE STATS. There can be a benefit to caching queries that evaluate to a zero cost, such as queries that are issued every time a connection is made to the server, like SET ANSI_NULLS ON. Similarly, CURSOR SELECT and API CURSOR FETCH are marked as cacheable even though they are zero-cost. In SQL Server 2005, the SET OPTIONS statement and transaction statements are marked as cacheable even though zero-cost, which will almost always cause the entire query to be marked as cacheable.

27 Module 8: Implementing Stored Procedures 8-25 Query Compilation When SQL Server receives a query for execution, it first checks the procedure cache for a cached execution plan. If it finds one, then it uses the cached plan to execute the query. If it does not find a cached execution plan, then the query is compiled, the execution plan is cached, and then the query is executed. The compilation process consists of the following four stages: 1. Parsing. SQL Server checks the query for syntax errors and prepares it for optimization. At this stage, SQL Server does not check object or column names. 2. Normalization. SQL Server verifies that all object and column names in the query are correct and valid. SQL Server also checks that the query is actually meaningful. 3. Compilation. SQL Server builds the execution plan for the query, creating query graphs for any DML statements. These query graphs are used by the optimizer to create an optimized plan that is then stored in the procedure cache. 4. Optimization. The SQL Server optimizer uses a cost-based approach to ascertain the cost of different possible execution plans, to determine the lowest-cost plan. If there is only one path through your query statements, then there is no need to optimize the plan.

28 8-26 Module 8: Implementing Stored Procedures Forcing Stored Procedure Recompilation Sometimes SQL Server needs to re-optimize stored procedure execution plans. For example, when you add new indexes or change the data in indexed columns. To do this, you can recompile the stored procedure. When SQL Server restarts, this optimization happens automatically when the query is first run. This optimization also happens automatically when you change any underlying tables. However, if you add a new index for example, you must manually recompile a stored procedure. It can also be beneficial to recompile a stored procedure to circumvent the parameter sniffing feature of stored procedure compilation. Along with the optimized query plan, the execution plan includes the execution context, which includes parameter values. If these values are not the typical values for subsequent calls, then you may find that performance may suffer and it may be beneficial to recompile the stored procedure. Recompiling Stored Procedures There are three different ways to force the recompilation of a stored procedure in SQL Server: The sp_recompile system stored procedure forces the specified stored procedure to be recompiled the next time that it is run. You can specify a stored procedure, trigger, table, or view in the current database. The WITH RECOMPILE option of the CREATE PROCEDURE statement instructs SQL Server to not store an execution plan for that stored procedure in the procedure cache. SQL Server recompiles the stored procedure each time it is run. You should use this approach when the stored procedure parameter values vary greatly from one execution to the next.

29 Module 8: Implementing Stored Procedures 8-27 The WITH RECOMPILE option of the EXEC statement instructs SQL Server to recompile the stored procedure first when you execute the stored procedure. You should use this approach when the parameter values for this execution vary greatly from the typical values. The following example shows how to recompile all stored procedures that act on the Customers table by using the sp_recompile system stored procedure. USE AdventureWorks; GO EXEC sp_recompile N'Sales.Customer'; GO

30 8-28 Module 8: Implementing Stored Procedures Lesson 4: Handling Errors This lesson introduces the Microsoft SQL Server 2005 structured exception-handling technique. Exception handling is an important requirement for many Transact-SQL statements, particularly those that involve transactions. Structured exception handling reduces the amount of work required to handle errors and makes your code more reliable. Objectives After completing this lesson, you will be able to: Use structured exception handling. Describe the guidelines for handling errors.

31 Module 8: Implementing Stored Procedures 8-29 Syntax for Structured Exception Handling Structured exception handling is a common way to handle exceptions in many popular programming languages, such as Microsoft Visual Basic and Visual C#. SQL Server 2005 allows you to use structured exception handling in any transactional situation, such as a stored procedure. This makes your code more readable and more maintainable. Syntax for Structured Error Handling Use TRY CATCH blocks to implement structured exception handling. The TRY block contains the transactional code that could potentially fail. The CATCH block contains the code that executes if an error occurs in the TRY block. TRY CATCH has the following syntax. BEGIN TRY { sql_statement statement_block } END TRY BEGIN CATCH { sql_statement statement_block } END CATCH The sql_statement or statement_block part of the syntax is any Transact-SQL statement or group of statements. Example of TRY CATCH In this example, a stored procedure named AddData attempts to insert two values into a table named TestData. The first column of the TestData table is an integer primary key, and the second column is an integer data type. A TRY CATCH block within the AddData stored procedure protects the TestData INSERT statement and returns the error number and error message as part of the CATCH block logic by using the ERROR_NUMBER and ERROR_MESSAGE functions.

32 8-30 Module 8: Implementing Stored Procedures CREATE TABLE dbo.tablewithkey (ColA int PRIMARY KEY, ColB int) GO CREATE PROCEDURE int AS BEGIN TRY INSERT INTO TableWithKey END TRY BEGIN CATCH SELECT ERROR_NUMBER() ErrorNumber, ERROR_MESSAGE() [Message] END CATCH GO EXEC dbo.adddata 1, 1 EXEC dbo.adddata 2, 2 EXEC dbo.adddata 1, 3 --violates the primary key

33 Module 8: Implementing Stored Procedures 8-31 Guidelines for Handling Errors Creating the CATCH Block Create the CATCH block immediately following the END TRY statement by using the BEGIN CATCH and END CATCH statements. You cannot include any other statement between the END TRY and BEGIN CATCH statements. The following example will not compile. BEGIN TRY -- INSERT INTO... END TRY SELECT * FROM TableWithKey -- NOT ALLOWED BEGIN CATCH -- SELECT ERROR_NUMBER() END CATCH Rolling Back Failed Transactions Using transactions allows you to group together multiple statements so that either they all complete successfully or none of them complete successfully. Consider the following example, which does not use transactions. CREATE TABLE dbo.tablenokey (ColA int, ColB int) CREATE TABLE dbo.tablewithkey (ColA int PRIMARY KEY, ColB int) GO CREATE PROCEDURE int AS BEGIN TRY INSERT dbo.tablenokey VALUES INSERT dbo.tablewithkey VALUES END TRY BEGIN CATCH SELECT ERROR_NUMBER() ErrorNumber, ERROR_MESSAGE() [Message]

34 8-32 Module 8: Implementing Stored Procedures END CATCH GO EXEC dbo.adddata 1, 1 EXEC dbo.adddata 2, 2 EXEC dbo.adddata 1, 3 --violates the primary key This example performs two sequential inserts into two different tables. The first insert will always succeed because there is no primary key constraint on the table. The second insert will fail whenever a duplicate ColA value is inserted. Because transactions are not used in this example, the first insert succeeds even when the second insert fails, potentially leading to unexpected results. The following example uses transactions to ensure that neither insert succeeds if any one of the inserts fails. It does this by using BEGIN TRAN and COMMIT TRAN statements within the TRY block and a ROLLBACK TRAN statement within the CATCH block. ALTER PROCEDURE int AS BEGIN TRY BEGIN TRAN INSERT dbo.tablenokey VALUES INSERT dbo.tablewithkey VALUES COMMIT TRAN END TRY BEGIN CATCH ROLLBACK TRAN SELECT ERROR_NUMBER() ErrorNumber, ERROR_MESSAGE() [Message] END CATCH GO Using XACT_ABORT and XACT_STATE The XACT_ABORT option specifies whether SQL Server automatically rolls back the current transaction when a Transact-SQL statement raises a run-time error. However, if the error occurs within a TRY block, the transaction is not automatically rolled back; instead, it becomes uncommittable. Code within a CATCH block should test for the state of a transaction by using the XACT_STATE function. XACT_STATE returns a 1 if an uncommittable transaction is present in the current session. The CATCH block must not attempt to commit the transaction and should roll back the transaction manually. A returned value of 1 from XACT_STATE means that there is a transaction that can be safely committed. A returned value of 0 means that there is no current transaction. The following example sets XACT_ABORT ON and tests the transaction state within the CATCH block. SET XACT_ABORT ON BEGIN TRY BEGIN TRAN... COMMIT TRAN END TRY

35 Module 8: Implementing Stored Procedures 8-33 BEGIN CATCH IF (XACT_STATE()) = -1 ROLLBACK TRAN ELSE IF (XACT_STATE()) = 1 COMMIT TRAN END CATCH -- uncommittable -- committable For more information about using XACT_ABORT and XACT_STATE, see Using TRY...CATCH in Transact-SQL in SQL Server Books Online. Capturing Error Information If Required SQL Server provides several error-related functions that you can call within your CATCH block for logging error information. For example, you could call these methods and store the results in an error log table. The following table lists the error functions. Function ERROR_LINE ERROR_MESSAGE ERROR_NUMBER ERROR_PROCEDURE ERROR_SEVERITY Description Returns the line number at which the error occurred that caused the CATCH block code to execute. Returns diagnostic information about the cause of the error. Many error messages have substitution variables in which information, such as the name of the object generating the error, is placed. Returns the unique number for the error that occurred. Returns the name of the stored procedure or trigger in which the error occurred. Returns a value indicating how serious the error is. Errors with a low severity, such as 1 or 2, are information messages or low-level warnings. Errors with a high severity indicate problems that should be addressed as soon as possible. ERROR_STATE Returns the state value. Some error messages can be raised at multiple points in the code for the database engine. Each specific condition that raises an error assigns a unique state code. This information can be useful when you are working with Microsoft Knowledge Base articles to determine whether the recorded issue is the same as the error you have encountered. For more information about error severity levels, see Database Engine Error Severities in SQL Server Books Online.

36 8-34 Module 8: Implementing Stored Procedures Practice: Handling Errors The purpose of this practice is to enable you to add error handling to a stored procedure, which is an important requirement for many Transact-SQL statements, particularly those that involve transactions. Structured exception handling reduces the amount of work required to handle errors and makes your code more reliable. Objectives In this practice, you will add error handling to a stored procedure. Instructions Start the 2779B-MIA-SQL-08 virtual machine Log on to the virtual machine with the user name Student and the password Pa$$w0rd. Add error handling to a stored procedure 1. Click Start, point to All Programs, point to Microsoft SQL Server 2005, and then click SQL Server Management Studio. 2. In the Connect to Server dialog box, specify the values in the following table, and then click Connect. Property Server type Server name Authentication Value Database Engine MIAMI Windows Authentication 3. On the File menu, point to Open, and then click File.

37 Module 8: Implementing Stored Procedures In the Open File dialog box, navigate to the D:\Practices folder, click the ErrorHandling.sql query file, and then click Open. 5. In the Connect to Database Engine dialog box, specify the values in the following table, and then click Connect. Property Server name Authentication Value MIAMI Windows Authentication 6. Select the code under the comment Create procedure without error handling, and then on the toolbar, click Execute. 7. Review the query output and confirm that the command completed successfully. 8. Select the EXECUTE and SELECT queries under the comment Test stored procedure without error handling, and then on the toolbar, click Execute. 9. Review the query results. Notice that the review was added successfully to the table. 10. Change parameter value from 4 to Reselect the EXECUTE and SELECT queries under the comment Test stored procedure without error handling, and then on the toolbar, click Execute. 12. Review the query results. Notice that the insert fails because of a CHECK constraint on the ratings column. 13. Select the ALTER PROCEDURE statement under the comment Implement error handling, and then on the toolbar, click Execute. 14. Review the query output and confirm that the command completed successfully. 15. Select the EXECUTE query under the comment Test stored procedure with error handling, and then on the toolbar, click Execute. 16. Review the query results. Notice that the error number and message are displayed because the CATCH block handles the error successfully. 17. Select the DROP PROCEDURE statement at the end of the file, and then on the toolbar, click Execute. 18. Close SQL Server Management Studio without saving any changes to the file. After you complete the practice, you must shut down the 2779B-MIA-SQL-08 virtual machine and discard any changes. Important: If the Close dialog box appears, ensure that Turn off and delete changes is selected, and then click OK.

38 8-36 Module 8: Implementing Stored Procedures Lab: Implementing Stored Procedures After completing this lab, you will be able to: Create stored procedures. Work with execution plans. Estimated time to complete this lab: 60 minutes Lab Setup For this lab, you will use the available virtual machine environment. Before you begin the lab, you must: Start the 2779B-MIA-SQL-08 virtual machine. Log on to the virtual machine with the user name Student and the password Pa$$w0rd. Lab Scenario Adventure Works maintains a list of special offers and discounts for various products throughout the year that applies to both customers and resellers. Currently, this information is only accessible directly from the Sales.SpecialOffer table. A new requirement is to retrieve this information by using stored procedures, in addition to inserting new special offers by using a stored procedure. The senior database developer has provided you with a SQL Server Scripts project named AWProgrammability.ssmssln in the D:\Labfiles\Starter folder and has specified the following requirements for the modifications you must make:

39 Module 8: Implementing Stored Procedures 8-37 Create a stored procedure named GetDiscounts within the Sales schema that retrieves the following columns from Sales.SpecialOffer: Description, DiscountPct, Type, Category, StartDate, EndDate, MinQty, and MaxQty. The procedure should return all rows sorted by StartDate and EndDate. Create a stored procedure named GetDiscountsForCategory within the Sales schema that accepts an input parameter which is an nvarchar data type accepting up to 50 characters. The procedure should retrieve the same columns as for GetDiscounts, but should filter the rows based on parameter. Create a stored procedure named GetDiscountsForCategoryAndDate within the Sales schema that accepts parameter as for GetDiscountsForCategory, but includes an datetime input parameter. parameter must be able to accept a NULL default value. If a NULL value is specified for parameter, set the parameter value to the current date and time by using the GETDATE function. The procedure should retrieve the same columns as for GetDiscounts, but should filter the rows based on parameters. Create a stored procedure named AddDiscount within the Sales schema that inserts new records into the Sales.SpecialOffer table. The following table specifies the required parameters for the insert. DiscountedPrice Data type (input unless otherwise specified) nvarchar(255) smallmoney nvarchar(50) nvarchar(50) datetime datetime The INSERT statement must be protected by appropriate error handling and any errors must be logged in the dbo.errorlog table. If the new insert succeeds, parameter must be updated with the SCOPE_IDENTITY function value. A return value must also indicate success or failure for the insert. Additional Information When performing database development tasks, it can be helpful to use SQL Server Management Studio to create a SQL Server Scripts project, and use it to document the Transact-SQL code necessary to re-create the solution if necessary. int int int

40 8-38 Module 8: Implementing Stored Procedures Use the following procedure to create a SQL Server Scripts project: 1. Open SQL Server Management Studio, connecting to the server you want to manage. 2. On the File menu, point to New, and then click Project. 3. Select the SQL Server Scripts template and enter a suitable name and location for the project. Note that you can create a solution that contains multiple projects, but in many cases a single project per solution is appropriate. Use the following procedure to add a query file to a project: 1. On the Project menu, click New Query, or in Solution Explorer, right-click the Queries folder, and then click New Query. If Solution Explorer is not visible, on the View menu, click Solution Explorer. 2. When prompted, connect to the server on which you want to execute the query. This will add a connection object to the project. 3. To change the name of the query file from the default name (SQLQuery1.sql), rightclick it in Solution Explorer and click Rename. Although you can perform all database development tasks by executing Transact-SQL statements, it is often easier to use the graphical user interface in SQL Server Management Studio. However, you should generate the corresponding Transact-SQL scripts and save them in the project for future reference. Often, you can generate the Transact-SQL script for an action before clicking OK in the Properties dialog box used to perform the action. Many Properties dialog boxes include a Script list with which you can script the action to a new query window, a file, the Clipboard, or a SQL Server Agent job. A common technique is to add a blank query file to a project, script each action to the Clipboard as it is performed, and then paste the generated script into the query file. You can also generate scripts for many existing objects, such as databases and tables. To generate a script, right-click the object in Object Explorer and script the CREATE action. If Object Explorer is not visible, on the View menu, click Object Explorer.