Stored Procedures

A stored procedure is a group of SQL statements compiled into an execution plan and stored under a unique name in the database. It is then executed as a unit. Stored procedures in SQL Server and Oracle are similar to queries in Access. However, stored procedures are much more flexible and powerful than queries, as you'll discover in later chapters when you start implementing more complex stored procedures.

Each database vendor provides tools that enable you to work with the objects within their databases and to view and create stored procedures. For example, Microsoft provides the Query Analyzer for SQL Server, whereas Oracle provides SQL Plus and SQLPlus Worksheet for Oracle.

However, Visual Studio .NET also provides tools for viewing and creating stored procedures in SQL Server and Oracle. Although these tools are not as robust as the database vendors' tools, they do the job and enable you to develop database applications without having to leave the development environment.

Before you begin using Visual Studio .NET to develop stored procedures, you'll need to take a look at the basic syntax for creating stored procedures in SQL Server and Oracle. The following example is a basic stored procedure that will insert group data into the Groups table in SQL Server:

The INSERT statement for this stored procedure is similar to the INSERT statement that you created for your usp_InsertGroup query in Chapter 7. The only difference is instead of using the built-in Access function to insert a date and time into the LastUpdateDate column, you are using the built-in SQL Server function GETDATE().

When you built your Access query, you didn't need to specify the input parameters to the query or their data types. That is inferred by Access, and Access will prompt you for them when running the query within Access. When you ran your query from your VB.NET program, you knew what parameters to specify and the order in which to specify them based on their use in your INSERT statement. You also knew their data types as specified in the column definition when you created the tables. This is not the case with stored procedures.

You create a stored procedure with a CREATE PROCEDURE statement and then specify the input and/or output parameters to the stored procedure. You also specify the parameter data types as you want them submitted to your stored procedure. A case in point is the example stored procedure listed previously.

Another important point regarding input parameters and variables in general when dealing with SQL Server stored procedures is that the parameters and variables must begin with an at (@) sign as shown in the previous example. This identifies the parameters and variables as variables local to the stored procedure, unlike SQL Server's global variables, which begin with two at signs and are global to all stored procedures.

Let's examine the syntax of the previous example that creates a stored procedure for SQL Server. You must specify the statement CREATE PROCEDURE to create a new stored procedure in SQL Server. This is followed by the stored procedure name, which can be up to 128 characters in length. You then specify the parameters for the stored procedure and their data types. Enclosing the parameters in a set of parentheses is totally optional in SQL Server but will be done here to be consistent with Oracle, which does require them.

Each parameter begins with an at sign (@) followed by the name of the parameter. Each parameter has the data type of the parameter specified, and if the data type allows a varying number of characters or digits, that must also be specified. For example, the @GroupName parameter in the previous example specifies a data type of VARCHAR. Because this data type allows a varying number of characters, you must also specify the maximum number of characters that will be allowed in the parameter.

After you have specified the CREATE PROCEDURE statement, the stored procedure name, and the parameters, you specify the AS keyword followed by the body of the stored procedure. The body of the stored procedure will be made up of one or more sets of SQL statements, such as the INSERT statement. The VALUES clause of the INSERT statement shown in the example contains the parameters as the source of input for the INSERT statement.

Now that you've had a look at how to create stored procedures in SQL Server, turn your attention to how a stored procedure is created in Oracle. An example of the usp_InsertGroup stored procedure for Oracle is shown here for reference:

In Oracle, you specify the CREATE OR REPLACE PROCEDURE statement to create a stored procedure, followed by the stored procedure name. You should note that a stored procedure name in Oracle is limited to 30 characters.

Next, you must specify the stored procedure parameters inside a set of parentheses. Each parameter is given a name, followed by the data type of the parameter. Note that an at sign (@) is an illegal character in Oracle so the parameters in the example above have been prefixed with the word in to indicate that these are input parameters. Also note that you do not specify the size of the data type for data types that allow a varying number of characters.

After you have specified the parameters for the stored procedure, you specify the AS keyword and then specify the BEGIN clause. This is followed by the body of the stored procedure, and the BEGIN clause is terminated with a matching END clause and a semicolon.

The body of the stored procedure in this example contains the INSERT statement, which you have become very familiar with. The VALUES clause for this INSERT statement contains the parameters for the stored procedure as the source of input for the INSERT statement. The complete INSERT statement is terminated with a semicolon. It is important to note that every SQL statement in Oracle must be terminated with a semicolon character.

As you can see from the two previous examples, the stored procedure in SQL Server is not all that different from the stored procedure in Oracle. The INSERT statement is the same and uses the parameters for the stored procedure as the source of input for the VALUES clause. There are very minor differences in the syntax for creating a stored procedure in SQL Server and Oracle, as you saw in the previous examples.

Oracle packages

The Oracle stored procedure that you examined previously works well as a stored procedure that inserts data into a table. In fact, stored procedures that insert, update, and delete data in Oracle work in the same manner as they do for SQL Server. You call the stored procedure from your code and pass it the required parameters and the data is inserted, updated, or deleted.

However, the major difference between SQL Server and Oracle becomes apparent when you are using a stored procedure to return data. This is a stored procedure that executes a SQL SELECT statement and returns the results of the SELECT statement back to the caller. Stored procedures that execute SELECT statements in SQL Server behave just like the queries you wrote in Access that execute SELECT statements. However, to have a stored procedure in Oracle return data from a SELECT statement, you must encapsulate the stored procedure in a package.

A package in Oracle can be thought of in the same terms as a class in VB.NET. A package, like a class in VB.NET, can contain variables, functions, and procedures. In fact, your package can even contain overloaded stored procedures. That is, multiple stored procedures are defined with the same name but each stored procedure accepts a different number of parameters.

However, for our discussion here, you want to examine a simple package that contains a single variable declaration and a single stored procedure. The package itself contains the definition for the stored procedure along with its parameters. However, the stored procedure is created in what is known as the package body. Every package contains the definition of the stored procedures within it and the package body contains the actual stored procedures.

Take a look at an example of a package that will perform the same function as your usp_SelectGroups query in Access. The code that follows creates a package that defines a variable named CURSOR_TYPE as a REF CURSOR and a stored procedure definition named usp_SelectGroups. Then the package body is created, and within the package body, the actual stored procedure is created.

A REF CURSOR is a cursor variable in Oracle that can be used by a stored procedure to return data. The stored procedure opens the cursor and populates the cursor with data from the SELECT statement. Then the application that calls the stored procedure fetches the data from the cursor.

Creating a package is a two-step process. First you create the package itself using the CREATE OR REPLACE PACKAGE statement followed by the name of the package, which in this example is GroupsPackage. This is followed by the AS keyword and the definition of the package.

The definition of this package contains a variable declaration with a variable named CURSOR_TYPE and is defined as a REF CURSOR. Then the stored procedure definition is specified with the PROCEDURE clause and the name of the stored procedure, along with its parameters, direction, and type. You can distinguish input and output parameters by the inclusion of the OUT keyword. Input parameters can contain the IN keyword but this is the default, and if not specified, the parameter is assumed to be an input parameter. You end the package with the END keyword and a semicolon.

Before you can create the package body, the package itself must be created. You need to signal to Oracle to execute the batch of statements to create the package before creating the package body. You accomplish this by using a forward slash (/). This signals Oracle to execute the preceding batch of statements and to commit them before continuing to the next set of statements, which create the package body.

The package body is created by using the CREATE OR REPLACE PACKAGE BODY statement followed by the package name, which is the package that this package body will belong to. This is followed by the AS keyword and then the statements to create the stored procedures for the package, which in this case is only one stored procedure.

Because the stored procedure is part of a package body, you specify only the PROCEDURE statement to create the stored procedure, followed by the stored procedure name and the parameters for the stored procedure contained in parentheses. Then, the AS keyword is specified, followed by the BEGIN clause.

Next comes the body of the stored procedure. In this example, you must open the cursor using the OPEN statement followed by the cursor name, which is the output parameter to this stored procedure. This is followed by the FOR keyword and then the SELECT statement. The SELECT statement will select all data from the Groups table and place the results of that SELECT statement in the cursor.

The stored procedure is terminated by an END clause and the package body is also terminated by the END clause. Another forward slash has been included so that Oracle will immediately create the package body and commit those statements before it proceeds to the next statement. (In this case, there are none.) This is just a good coding habit to get into when executing multiple statements in Oracle to prevent unnecessary errors.

Enough about packages and stored procedures; now its time to get your feet wet with hands-on exercises.

Try It Out: Creating Stored Procedures and Packages

In this exercise, you'll be creating stored procedures in SQL Server and stored procedures and packages in Oracle that mirror the functionality of the queries that currently exist in your ProjectTimeTracker Access database.

The steps in this exercise and the exercises to come will tell you when something is specific to SQL Server and when something is specific to Oracle. This will enable a single set of instructions to be used by all readers, regardless of the database that you are using.

To create your stored procedures:

1. Start Visual Studio .NET if it is not started. You do not need a project open to complete this exercise, so you can close any existing project that you may have open.

2. View the Server Explorer window and click the Auto Hide icon on the window to keep it visible.

3. View the Stored Procedures node for your database.

SQL Server

Expand the Servers node and expand the computer node on which SQL Server is running. Then expand the SQL Servers node and expand the SQL Server instance node on which your database is running. Expand the ProjectTimeTracker database node next and click the Stored Procedures node. There should be no stored procedures as you have not created any yet.

Oracle

Expand the Data Connections node and expand the Oracle connection that was created by the Oracle Data Wizard project from Chapter 3. You will be prompted with the Microsoft OLE DB for Oracle Connect dialog box. Enter your password and click OK to establish a connection to Oracle. Then click the Stored Procedures node and expand it. Stored procedures may exist for other database tables if the samples were installed with this instance of Oracle.

4. There are 10 stored procedures in Access that you'll need to create in your SQL Server or Oracle database. Either right-click the Stored Procedures node and choose New Stored Procedure or click the Database menu and choose New Stored Procedure. This causes a stored procedure template to be added to Visual Studio .NET. Enter the following code in this template:

Click the Save icon on the toolbar to have the stored procedure created in your database. You'll see that the usp_DeleteGroup stored procedure has been added to the Stored Procedures node in Server Explorer.

5. To create the usp_DeleteProject stored procedure, right-click the Stored Procedures node and choose New Stored Procedure from the context menu or click the Database menu and choose New Stored Procedure and enter the following code:

Click the Save icon on the toolbar to create the stored procedure in your database.

6. To create the usp_InsertGroup stored procedure, right-click the Stored Procedures node and choose New Stored Procedure or click the Database menu and choose New Stored Procedure. Enter the following code: