Stored procedure are compiled SQL code stored in database. Calling stored procedure as opposed to sending over query strings improves the performance of a web application. Not only is there less network traffic since only short commands are sent instead of long query stings, but the execution of the actually code itself also improves. The reason is because a stored procedure is already compiled ahead of time. Stored procedures are also cached by SQL Server when they are run to speed things up for subsequent calls.
Other than performance, stored procedures are also helpful because they provide another layer of abstraction for your web application. For instance, you can change a query in a stored procedure and get different results without having to recompile your objects. Using stored procedures also makes your objects cleaner, and SQL Server’s convenient backup tool makes it easy to back them up.
There are various options that can be used to create stored procedures. In these next few topics we will discuss creating a simple stored procedure to more advanced options that can be used when creating stored procedures.
Creating a simple stored procedure To create a stored procedure to do this the code would look like this:
CREATE PROCEDURE dbo.USP_projName_modulename
AS SELECT * FROM dbo.tblName
GOTo call the procedure to return the contents from the table specified, the code would be:
EXEC USP_projName_modulename
--or just simply
USP_projName_modulename
When creating a stored procedure you can either use
CREATE PROCEDURE or
CREATE PROC. After the stored procedure name you need to use the keyword "AS" and then the rest is just the regular SQL code that you would normally execute.
One thing to note is that you cannot use the keyword "GO" in the stored procedure. Once the SQL Server compiler sees "GO" it assumes it is the end of the batch.
Stored procedure with parametersThe real power of stored procedures is the ability to pass parameters and have the stored procedure handle the differing requests that are made.
In this example we will query the address table from the master database, but instead of getting back all records we will limit it to just a particular city. This example assumes there will be an exact match on the City value that is passed.
CREATE PROCEDURE dbo.USP_abc_GetMembersBasedOnCity
(
@City nvarchar(30)
)
ASSELECT *
FROM dbo.address
WHERE City = @City
GOTo call this stored procedure we would execute it as follows:
EXEC USP_abc_GetMembersBasedOnCity @City = 'Delhi'
In most cases it is always a good practice to pass in all parameter values, but sometimes it is not possible. So in this example we use the NULL option to allow you to not pass in a parameter value. If we create and run this stored procedure as is it will not return any data, because it is looking for any City values that equal NULL.
CREATE PROCEDURE dbo.USP_abc_GetMembersBasedOnCity @City nvarchar(30) = NULL
ASSELECT *
FROM dbo.address
WHERE City = @City
GO We could change this stored procedure and use the ISNULL function to get around this. So if a value is passed it will use the value to narrow the result set and if a value is not passed it will return all records.
CREATE PROCEDURE dbo.USP_abc_GetMembersBasedOnCity @City nvarchar(30) = NULL
ASSELECT *
FROM dbo.address
WHERE City = ISNULL(@City,City)
GOAbove we discussed how to pass parameters inside SPs, but there is one other option, to pass parameter values backout from SP.
Setting up output paramters for a stored procedure is basically the same as setting up input parameters, the only difference is that you use the
OUTPUT clause after the parameter name to specify that it should return a value. The output clause can be specified by either using the keyword "
OUTPUT" or just "
OUT".
CREATE PROCEDURE dbo.USP_abc_GetMembersBasedOnCity (
@City nvarchar(30),
@AddressCount int OUTPUT
)
ASSELECT @AddressCount = count(*)
FROM address
WHERE City = @City
GoTo call this stored procedure we would execute it as follows. First we are going to declare a variable, execute the stored procedure and then select the returned valued.
DECLARE @AddressCount
intEXEC USP_abc_GetMembersBasedOnCity @City = 'Calgary', @AddressCount = @AddressCount
OUTPUTSELECT @AddressCount
Using try catch in SQL Server stored proceduresDoing error handling in SQL Server has not always been the easiest thing, so this option definitely makes it much easier to code for and handle errors.
If you are not familiar with the Try...Catch paradigm it is basically two blocks of code with your stored procedures that lets you execute some code, this is the Try section and if there are errors they are handled in the Catch section.
Let's take a look at an example of how this can be done. As you can see we are using a basic SELECT statement that is contained within the TRY section, but for some reason if this fails it will run the code in the CATCH section and return the error information.
CREATE PROCEDURE uspTryCatchTest
ASBEGIN TRY SELECT 1/0
END TRYBEGIN CATCH SELECT ERROR_NUMBER() AS ErrorNumber
,ERROR_SEVERITY() AS ErrorSeverity
,ERROR_STATE() AS ErrorState
,ERROR_PROCEDURE() AS ErrorProcedure
,ERROR_LINE() AS ErrorLine
,ERROR_MESSAGE() AS ErrorMessage;
END CATCHNaming conventions for SQL Server stored procedures1- One of the things you do not want to use as a standard is "sp_". This is a standard naming convention that is used in the master database. If you do not specify the database where the object is, SQL Server will first search the master database to see if the object exists there and then it will search the user database. So avoid using this as a naming convention.
I liked to first give the action that the stored procedure takes and then give it a name representing the object it will affect.
So based on the actions that you may take with a stored procedure, you may use:
* Insert
* Delete
* Update
* Select
* Get
* Validate
* etc...
So here are a few examples:
* USP_projName_personDelete
* USP_projName_personGetData
Reducing amount of network data for SQL Server stored proceduresThere are many tricks that can be used when you write T-SQL code. One of these is to reduce the amount of network data for each statement that occurs within your stored procedures. Every time a SQL statement is executed it returns the number of rows that were affected. By using "SET NOCOUNT ON" within your stored procedure you can shut off these messages and reduce some of the traffic.
Not using SET NOCOUNT ONCREATE PROCEDURE uspGetAddress @City nvarchar(30)
ASSELECT *
FROM AdventureWorks.Person.Address
WHERE City = @City
GOThe messages that are returned would be similar to this:
20 rows affected
Using SET NOCOUNT ON-- using SET NOCOUNT ONCREATE PROCEDURE uspGetAddress @City nvarchar(30)
ASSET NOCOUNT ONSELECT *
FROM AdventureWorks.Person.Address
WHERE City = @City
GOThe messages that are returned would be similar to this:
Command(s) completed successfully.
Using SET NOCOUNT ON and @@ROWCOUNT-- not using SET NOCOUNT ONCREATE PROCEDURE uspGetAddress @City nvarchar(30)
ASSET NOCOUNT ONSELECT *
FROM AdventureWorks.Person.Address
WHERE City = @City
PRINT @@ROWCOUNT
GOThe messages that are returned would be similar to this:
20
Dropping Single Stored ProcedureTo drop a single stored procedure you use the DROP PROCEDURE or DROP PROC command as follows.
DROP PROCEDURE uspGetAddress
Dropping Multiple Stored ProceduresDROP PROCEDURE uspGetAddress, uspInsertAddress, uspDeleteAddress
GO
