Templates
SSMS comes with a plethora of templates to use
to create database objects. These are especially handy when you want to
create a stored procedure and cannot remember the exact syntax. To see
a complete list of templates, select Template Explorer from the View
menu in the SSMS toolbar. This will launch the Template Explorer shown
in Figure 4.
Figure 4. Template Explorer
To create a new stored
procedure using a template expand the Stored Procedures node, and
double-click Create Stored Procedure (New Menu). This will populate a
new query editor window with the following template script:
-- ================================================
-- Template generated from Template Explorer using:
-- Create Procedure (New Menu).SQL
--
-- Use the Specify Values for Template Parameters
-- command (Ctrl-Shift-M) to fill in the parameter
-- values below.
--
-- This block of comments will not be included in
-- the definition of the procedure.
-- ================================================
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
-- =============================================
-- Author: <Author,,Name>
-- Create date: <Create Date,,>
-- Description: <Description,,>
-- =============================================
CREATE PROCEDURE <Procedure_Name, sysname, ProcedureName>
-- Add the parameters for the stored procedure here
<@Param1, sysname, @p1> <Datatype_For_Param1, , int> = <Default_Value_For_Param1, ,
0>,
<@Param2, sysname, @p2> <Datatype_For_Param2, , int> = <Default_Value_For_Param2, , 0>
AS
BEGIN
-- SET NOCOUNT ON added to prevent extra result sets from
-- interfering with SELECT statements.
SET NOCOUNT ON;
-- Insert statements for procedure here
SELECT <@Param1, sysname, @p1>, <@Param2, sysname, @p2>
END
GO
In this script, you replace all the stub values like @Param1 and Datatype_For_Param1 individually, or you can use the Specify Values for Template Parameters dialog box, shown in Figure 5.
To launch this dialog box, press Control, Shift, and the letter “M”
together, or select Specify Values for Template Parameters from the
Query menu in the SSMS toolbar.
Figure 5. The Specify Values for Template Parameters dialog box
Let’s begin with the preceding template and
create a simple stored procedure that adds two numbers. In the template
parameters dialog, type AddNumbers for the Procedure Name; type @num1 for the @Param1 value and @num2
for @Param2. Click the OK button, and the Query Editor window will be
updated with a script that contains the values that you entered in the
dialog box. From here, you can further modify this script as needed. To
make our AddNumbers procedure meaningful, we will have to add an output parameter @result and perform the addition by appending SELECT @result=@num1 +@num2 to the body of the stored procedure. The updated stored procedure follows, with changes in bold:
CREATE PROCEDURE AddNumbers
-- Add the parameters for the stored procedure here
@num1 int = 0,
@num2 int = 0,
@result int OUTPUT
AS
BEGIN
-- SET NOCOUNT ON added to prevent extra result sets from
-- interfering with SELECT statements.
SET NOCOUNT ON;
-- Insert statements for procedure here
SELECT @result=@num1 +@num2
END
GO
To test this procedure, you can run the following code:
DECLARE @i INT
EXECUTE AddNumbers 1,4,@i OUTPUT
SELECT @i
The result will be 5. This stored procedure is
very simple, but stored procedures used in regular applications can be
very complex. Troubleshooting stored procedures has, until recently,
been very difficult, so developers had many tactics to debug one that
misbehaved—injecting code within the stored procedure to track values
and adding code to force the values to name a few. If a problematic
procedure was written in C# or VB.NET, developers could easily set up
break points in the code, so that when the program hit that break
point, the execution would stop and control would be given to the
develop to step through the code line by line. It’s this advanced
debugging capability that is also part of SSMS for both T-SQL code and
CLR code within T-SQL stored procedures and user-defined functions.
Debugging in T-SQL
In the previous section, we created a stored procedure called AddNumbers.
Suppose we want to troubleshoot this procedure within SSMS. To do so,
we can add a breakpoint by clicking to the left of the statement where
we want SQL Server to pause or moving the cursor to the statement and
pressing the F9 key. The red circle added to the line indicate a
breakpoint; see Figure 6.
Figure 6. Breakpoint set on a T-SQL statement
To start debugging, click the debug button on
the toolbar or press Alt+F5. The first statement will execute, and then
the application will pause. A yellow arrow will show you the next
statement to be executed, which, in our example, is the EXECUTE
stored procedure statement. If you wanted SQL Server to execute the
stored procedure in its entirety without stepping into the procedure
and through each and every statement in it, you would click the Step
Over button or press F10.
Since we want to peek inside the
stored procedure and evaluate every line, click Step Into, or hit F11.
Once you click Step Into, you can see the source of the stored
procedure and the yellow arrow indicating the line to be executed next.
Notice the Locals pane on the bottom of the screen. The Locals window
shows variables and values in the given context. If you want to test a
certain code path, you can simply overwrite the value here and see how
the stored procedure behaves. Let’s change the value of @num2
to 5 instead of 4. Make sure that the “5” is colored red in the Locals
window by pressing the Enter key after you change the value. Press F11
repeatedly to step through the code, and you will see the result come
back as 6 (so one plus four really equals six). Being able to set
breakpoints and step through code is just one small example of the
power of debugging within SSMS. If you don’t want a breakpoint at every
iteration of the stored procedure, you can specify one of many
breakpoint conditions. For example, you can choose to only break only
when the value of a number is greater than 10. Then too, you could set
a breakpoint filter to break only on specific computers, processes, or
threads. Breakpoints can also be exported via an XML file so that you
can share them with others.
