Creating Executing Modifying Dropping
Creating Executing Modifying Dropping
SOURCE:https://www.mssqltips.com/sqlservertip/6132/create-alter-drop-and-e
xecute-sql-server-stored-procedures/
Problem
As a beginning SQL Server Developer \ DBA, I have the skills to design and manually run
T-SQL scripts. However, I am less clear on how to package my T-SQL scripts for easy
re-use by me and others. Please provide examples that illustrate the basics of creating,
altering, and running stored procedures to facilitate the re-use T-SQL code. Also, briefly
describe the use of input and output parameters as well as return code values associated
with stored procedures. Demonstrate a stored procedure that returns more than one result
set based on the value of an input parameter.
Solution
This tip gives you a quick introduction to the basics of creating, dropping and altering stored
procedures. You will also learn how to run a stored procedure to create a result set for
viewing.
Many blocks of T-SQL code can be run from a stored procedure. It is common to test the
initial version of code inside a T-SQL script file and later copy the code into the body of a
stored procedure shell.
After creating or modifying a stored procedure containing one or more SELECT statements,
you can invoke the stored procedure with an EXEC statement. Consequently, you can think
of a stored procedure as a container that facilitates the re-use of T-SQL code within it.
A stored procedure is a saved block of T-SQL code, such as a query to list the rows in a
table. A block of T-SQL code can be saved in a T-SQL script file. You can also store the
code from a script file in a stored procedure.
There are several benefits that result from saving code in a stored procedure rather than a
script file. These are some examples.
● You do not need to expose the code in a stored procedure in order to run its T-SQL
code. In contrast, users need to open a script file with its code in order to run the
code.
● Stored procedures also offer a means of limiting access to the underlying tables for a
query. By granting access to run stored procedures without permission to read or
write to the underlying tables, you can secure data but still allow visibility for data in
the underlying tables through a stored procedure.
● You can use input parameters with stored procedures to vary the operation of the
code inside a stored procedure. While script files do allow the use of local variables
to modify the return sets from queries, script files must expose their code to allow you
to modify local variables at run time.
● By gaining proficiency in segmenting a programming solution into parts based on
stored procedures, you make it easier to change code over time. By adding code in
short modular scripts, each script can be easier to read and maintain and even
re-use in other applications. Solutions based on SQL files with scripts for queries
can become increasingly long, difficult to read, and maintain as successive changes
continue to be made to a solution.
Stored procedures introduce a level of abstraction between the code for a solution and using
the code that is not present when you maintain your code in a script file. Therefore, if you
have a simple solution that is used by one user who needs to have access to the underlying
data sources for a query (or set of queries), then a script file may be better because it
simplifies the solution.
If you have appropriate permissions, you can use a CREATE DATABASE statement to make
a new database to hold tables and other kinds of objects, such as stored procedures. The
create database statement is normally restricted to a few login accounts on a SQL Server
instance.
The following script creates a database named CodeModuleTypes. Its first statement
specifies the master database as the default database. Its second statement creates the
database. It is possible to have much more elaborate versions of the CREATE DATABASE
statement depending on your needs. Unless you specify otherwise, a simple create
database statement like the one below will utilize default settings from the model database,
which is one of the standard databases that installs with SQL Server.
After you have a database, such as CodeModuleTypes, you can invoke a CREATE PROC
statement within that database. All stored procedures created in this tip are saved in the
CodeModuleTypes database.
The following script demonstrates a syntax that you can use to create your first stored
procedure. The stored procedure in the code below displays a result set with all columns for
each row from the Employee table in the HumanResources schema of the
AdventureWorks2014 database.
You can think of a schema as a way to logically group database objects, such as tables and
stored procedures. These logical groupings avoid name conflicts between objects with the
same name in different schema. Any one database can have multiple schemas. In this tip,
all stored procedures are designated as belonging to the dbo schema of the
CodeModuleTypes database.
● The CREATE PROC statement names the stored procedure (and its schema if you
are explicitly designating it).
● The as keyword acts as a marker to denote that the defining code for the stored
procedure is about to start.
● The T-SQL code defining the operation of the stored procedure. In this example, the
defining code is the SELECT statement for the Employee table in the
HumanResources schema of the AdventureWorks2014 database. This prior
MSSQLTips.com tip describes how to download a copy of the AdventureWorks2014
database.