What is a "stored procedure" and how do they work?
What is the make-up of a stored procedure (things each must have to be a stored procedure)?
Stored procedures are a batch of SQL statements that can be executed in a couple of ways. Most major DBMs support stored procedures; however, not all do. You will need to verify with your particular DBMS help documentation for specifics. As I am most familiar with SQL Server I will use that as my samples.
To create a stored procedure the syntax is fairly simple:
CREATE PROCEDURE <owner>.<procedure name>
<Param> <datatype>
AS
<Body>
So for example:
CREATE PROCEDURE Users_GetUserInfo
#login nvarchar(30)=null
AS
SELECT * from [Users]
WHERE ISNULL(#login,login)=login
A benefit of stored procedures is that you can centralize data access logic into a single place that is then easy for DBA's to optimize. Stored procedures also have a security benefit in that you can grant execute rights to a stored procedure but the user will not need to have read/write permissions on the underlying tables. This is a good first step against SQL injection.
Stored procedures do come with downsides, basically the maintenance associated with your basic CRUD operation. Let's say for each table you have an Insert, Update, Delete and at least one select based on the primary key, that means each table will have 4 procedures. Now take a decent size database of 400 tables, and you have 1600 procedures! And that's assuming you don't have duplicates which you probably will.
This is where using an ORM or some other method to auto generate your basic CRUD operations has a ton of merit.
A stored procedure is a set of precompiled SQL statements that are used to perform a special task.
Example: If I have an Employee table
Employee ID Name Age Mobile
---------------------------------------
001 Sidheswar 25 9938885469
002 Pritish 32 9178542436
First I am retrieving the Employee table:
Create Procedure Employee details
As
Begin
Select * from Employee
End
To run the procedure on SQL Server:
Execute Employee details
--- (Employee details is a user defined name, give a name as you want)
Then second, I am inserting the value into the Employee Table
Create Procedure employee_insert
(#EmployeeID int, #Name Varchar(30), #Age int, #Mobile int)
As
Begin
Insert Into Employee
Values (#EmployeeID, #Name, #Age, #Mobile)
End
To run the parametrized procedure on SQL Server:
Execute employee_insert 003,’xyz’,27,1234567890
--(Parameter size must be same as declared column size)
Example: #Name Varchar(30)
In the Employee table the Name column's size must be varchar(30).
A stored procedure is a group of SQL statements that has been created and stored in the database. A stored procedure will accept input parameters so that a single procedure can be used over the network by several clients using different input data. A stored procedures will reduce network traffic and increase the performance. If we modify a stored procedure all the clients will get the updated stored procedure.
Sample of creating a stored procedure
CREATE PROCEDURE test_display
AS
SELECT FirstName, LastName
FROM tb_test;
EXEC test_display;
Advantages of using stored procedures
A stored procedure allows modular programming.
You can create the procedure once, store it in the database, and call it any number of times in your program.
A stored procedure allows faster execution.
If the operation requires a large amount of SQL code that is performed repetitively, stored procedures can be faster. They are parsed and optimized when they are first executed, and a compiled version of the stored procedure remains in a memory cache for later use. This means the stored procedure does not need to be reparsed and reoptimized with each use, resulting in much faster execution times.
A stored procedure can reduce network traffic.
An operation requiring hundreds of lines of Transact-SQL code can be performed through a single statement that executes the code in a procedure, rather than by sending hundreds of lines of code over the network.
Stored procedures provide better security to your data
Users can be granted permission to execute a stored procedure even if they do not have permission to execute the procedure's statements directly.
In SQL Server we have different types of stored procedures:
System stored procedures
User-defined stored procedures
Extended stored Procedures
System-stored procedures are stored in the master database and these start with a sp_ prefix. These procedures can be used to perform a variety of tasks to support SQL Server functions for external application calls in the system tables
Example: sp_helptext [StoredProcedure_Name]
User-defined stored procedures are usually stored in a user database and are typically designed to complete the tasks in the user database. While coding these procedures don’t use the sp_ prefix because if we use the sp_ prefix first, it will check the master database, and then it comes to user defined database.
Extended stored procedures are the procedures that call functions from DLL files. Nowadays, extended stored procedures are deprecated for the reason it would be better to avoid using extended stored procedures.
Generally, a stored procedure is a "SQL Function." They have:
-- a name
CREATE PROCEDURE spGetPerson
-- parameters
CREATE PROCEDURE spGetPerson(#PersonID int)
-- a body
CREATE PROCEDURE spGetPerson(#PersonID int)
AS
SELECT FirstName, LastName ....
FROM People
WHERE PersonID = #PersonID
This is a T-SQL focused example. Stored procedures can execute most SQL statements, return scalar and table-based values, and are considered to be more secure because they prevent SQL injection attacks.
Think of a situation like this,
You have a database with data.
There are a number of different applications needed to access that central database, and in the future some new applications too.
If you are going to insert the inline database queries to access the central database, inside each application's code individually, then probably you have to duplicate the same query again and again inside different applications' code.
In that kind of a situation, you can use stored procedures (SPs). With stored procedures, you are writing number of common queries (procedures) and store them with the central database.
Now the duplication of work will never happen as before and the data access and the maintenance will be done centrally.
NOTE:
In the above situation, you may wonder "Why cannot we introduce a central data access server to interact with all the applications? Yes. That will be a possible alternative. But,
The main advantage with SPs over that approach is, unlike your data-access-code with inline queries, SPs are pre-compiled statements, so they will execute faster. And communication costs (over networks) will be at a minimum.
Opposite to that, SPs will add some more load to the database server. If that would be a concern according to the situation, a centralized data access server with inline queries will be a better choice.
A stored procedure is mainly used to perform certain tasks on a database. For example
Get database result sets from some business logic on data.
Execute multiple database operations in a single call.
Used to migrate data from one table to another table.
Can be called for other programming languages, like Java.
A stored procedure is nothing but a group of SQL statements compiled into a single execution plan.
Create once time and call it n number of times
It reduces the network traffic
Example: creating a stored procedure
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE PROCEDURE GetEmployee
#EmployeeID int = 0
AS
BEGIN
SET NOCOUNT ON;
SELECT FirstName, LastName, BirthDate, City, Country
FROM Employees
WHERE EmployeeID = #EmployeeID
END
GO
Alter or modify a stored procedure:
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
ALTER PROCEDURE GetEmployee
#EmployeeID int = 0
AS
BEGIN
SET NOCOUNT ON;
SELECT FirstName, LastName, BirthDate, City, Country
FROM Employees
WHERE EmployeeID = #EmployeeID
END
GO
Drop or delete a stored procedure:
DROP PROCEDURE GetEmployee
A stored procedure is used to retrieve data, modify data, and delete data in database table. You don't need to write a whole SQL command each time you want to insert, update or delete data in an SQL database.
A stored procedure is a precompiled set of one or more SQL statements which perform some specific task.
A stored procedure should be executed stand alone using EXEC
A stored procedure can return multiple parameters
A stored procedure can be used to implement transact
"What is a stored procedure" is already answered in other posts here. What I will post is one less known way of using stored procedure. It is grouping stored procedures or numbering stored procedures.
Syntax Reference
; number as per this
An optional integer that is used to group procedures of the same name. These grouped procedures can be dropped together by using one DROP PROCEDURE statement
Example
CREATE Procedure FirstTest
(
#InputA INT
)
AS
BEGIN
SELECT 'A' + CONVERT(VARCHAR(10),#InputA)
END
GO
CREATE Procedure FirstTest;2
(
#InputA INT,
#InputB INT
)
AS
BEGIN
SELECT 'A' + CONVERT(VARCHAR(10),#InputA)+ CONVERT(VARCHAR(10),#InputB)
END
GO
Use
exec FirstTest 10
exec FirstTest;2 20,30
Result
Another Attempt
CREATE Procedure SecondTest;2
(
#InputA INT,
#InputB INT
)
AS
BEGIN
SELECT 'A' + CONVERT(VARCHAR(10),#InputA)+ CONVERT(VARCHAR(10),#InputB)
END
GO
Result
Msg 2730, Level 11, State 1, Procedure SecondTest, Line 1 [Batch Start Line 3]
Cannot create procedure 'SecondTest' with a group number of 2 because a procedure with the same name and a group number of 1 does not currently exist in the database.
Must execute CREATE PROCEDURE 'SecondTest';1 first.
References:
CREATE PROCEDURE with the syntax for number
Numbered Stored Procedures in SQL Server - techie-friendly.blogspot.com
Grouping Stored Procedures - sqlmag
CAUTION
After you group the procedures, you can't drop them individually.
This feature may be removed in a future version of Microsoft SQL Server.
for simple,
Stored Procedure are Stored Programs, A program/function stored into database.
Each stored program contains a body that consists of an SQL statement. This statement may be a compound statement made up of several statements separated by semicolon (;) characters.
CREATE PROCEDURE dorepeat(p1 INT)
BEGIN
SET #x = 0;
REPEAT SET #x = #x + 1; UNTIL #x > p1 END REPEAT;
END;
A stored procedure is a named collection of SQL statements and procedural logic i.e, compiled, verified and stored in the server database. A stored procedure is typically treated like other database objects and controlled through server security mechanism.
In a DBMS, a stored procedure is a set of SQL statements with an assigned name that's stored in the database in compiled form so that it can be shared by a number of programs.
The use of a stored procedure can be helpful in
Providing a controlled access to data (end users can only enter or change data, but can't write procedures)
Ensuring data integrity (data would be entered in a consistent manner) and
Improves productivity (the statements of a stored procedure need to be written only once)
Stored procedures in SQL Server can accept input parameters and return multiple values of output parameters; in SQL Server, stored procedures program statements to perform operations in the database and return a status value to a calling procedure or batch.
The benefits of using stored procedures in SQL Server
They allow modular programming.
They allow faster execution.
They can reduce network traffic.
They can be used as a security mechanism.
Here is an example of a stored procedure that takes a parameter, executes a query and return a result. Specifically, the stored procedure accepts the BusinessEntityID as a parameter and uses this to match the primary key of the HumanResources.Employee table to return the requested employee.
> create procedure HumanResources.uspFindEmployee `*<<<---Store procedure name`*
#businessEntityID `<<<----parameter`
as
begin
SET NOCOUNT ON;
Select businessEntityId, <<<----select statement to return one employee row
NationalIdNumber,
LoginID,
JobTitle,
HireData,
From HumanResources.Employee
where businessEntityId =#businessEntityId <<<---parameter used as criteria
end
I learned this from essential.com...it is very useful.
Stored Procedure will help you to make code in server.You can pass parameters and find output.
create procedure_name (para1 int,para2 decimal)
as
select * from TableName
In Stored Procedures statements are written only once and reduces network traffic between clients and servers.
We can also avoid Sql Injection Attacks.
Incase if you are using a third party program in your application for
processing payments, here database should only expose the
information it needed and activity that this third party has been
authorized, by this we can achieve data confidentiality by setting
permissions using Stored Procedures.
The updation of table should only done to the table it is targeting
but it shouldn't update any other table, by which we can achieve
data integrity using transaction processing and error handling.
If you want to return one or more items with a data type then it is
better to use an output parameter.
In Stored Procedures, we use an output parameter for anything that
needs to be returned. If you want to return only one item with only
an integer data type then better use a return value. Actually the
return value is only to inform success or failure of the Stored
Procedure.
Preface: In 1992 the SQL92 standard was created and was popularised by the Firebase DB. This standard introduced the 'Stored Procedure'.
**
Passthrough Query: A string (normally concatenated programatically) that evaluates to a syntactically correct SQL statement, normally generated at the server tier (in languages such as PHP, Python, PERL etc). These statements are then passed onto the database.
**
**
Trigger: a piece of code designed to fire in response to a database event (typically a DML event) often used for enforcing data integrity.
**
The best way to explain what a stored procedure is, is to explain the legacy way of executing DB logic (ie not using a Stored Procedure).
The legacy way of creating systems was to use a 'Passthrough Query' and possibly have triggers in the DB.
Pretty much anyone who doesn't use Stored Procedures uses a thing call a 'Passthrough Query'
With the modern convention of Stored Procedures, triggers became legacy along with 'Passthrough Queries'.
The advantages of stored procedures are:
They can be cached as the physical text of the Stored Procedure
never changes.
They have built in mechanisms against malicious SQL
injection.
Only the parameters need be checked for malicious SQL
injection saving a lot of processor overhead.
Most modern database
engines actually compile Stored Procedures.
They increase the
degree of abstraction between tiers.
They occur in the same
process as the database allowing for greater optimisation and
throughput.
The entire workflow of the back end can be tested
without client side code. (for example the Execute command in
Transact SQL or the CALL command in MySQL).
They can be used to
enhance security because they can be leveraged to disallow the
database to be accessed in a way that is inconsistent with how the
system is designed to work. This is done through the database user
permission mechanism. For example you can give users privileges only
to EXECUTE Stored Procedures rather that SELECT, UPDATE etc
privileges.
No need for the DML layer associated with triggers. **
Using so much as one trigger, opens up a DML layer which is very
processor intensive **
In summary when creating a new SQL database system there is no good excuse to use Passthrough Queries.
It is also noteworthy to mention that it is perfectly safe to use Stored Procedures in legacy systems that already uses triggers or Passthrough Queries; meaning that migration from legacy to Stored Procedures is very easy and such migration need not take a system down for long if at all.
create procedure <owner>.<procedure name><param> <datatype>
As
<body>
Stored procedure are groups of SQL statements that centralize data access in one point. Useful for performing multiple operations in one shot.
Related
Background Information:
In Python, I might write something like this if I want to apply the same logic to different values in a list.
database_list = ["db_1", "db_2", "db_3"]
for x in range(0,len(database_list),1):
print("the database name is " + database_list[x])
What I am trying to do:
What I am trying to do in SSMS, is pull a list of DB objects for each database. I created a stored procedure to pull exactly what I want, but I have to run it against each database, so 10 databases mean running it 10 times.
My goal is to do this with a T-SQL query instead of Python.
I tried doing something like this:
exec sp_MSforeachdb 'USE ?; EXEC [dbo].[my_stored_procedure]';
The problem with this is, [dbo].[my_stored_procedure] has to exist in every database I want to do this in.
How can I create the stored procedure in 1 database, but execute it for all databases or a list of databases that I choose?
I know what you are trying to do and if it's what I think (you seem reluctant to actually say!) you can do the following:
In the master database, create your procedure. Normally you wouldn't do this, but in this case you must prefix it sp_
use master
go
create procedure sp_testproc as
select top 10 * from sys.tables
go
Now if you run this, it will return tables from the master database.
If you switch context to another database and exec master.dbo.sp_testproc, it will still return tables from the master database.
In master, run
sys.sp_MS_marksystemobject sp_testproc
Now switch context to a different database and exec master.dbo.sp_testproc
It will return tables from the database you are using.
Try creating your sproc in master and naming it with an sp_ prefix:
USE master
GO
CREATE PROCEDURE sp_sproc_name
AS
BEGIN
...
END
GO
-- You *may* need to mark it as a system object
EXEC sys.sp_MS_marksystemobject sp_sprocname
See: https://nickstips.wordpress.com/2010/10/18/sql-making-a-stored-procedure-available-to-all-databases/
It should then be available in all dbs
Create the stored procedure in the Master database with the sp_ prefix, and use dynamic SQL in the stored procedure so it resolves object names relative to the current database, rather than the database which contains the stored procedure.
EG
use master
go
CREATE OR ALTER PROCEDURE [dbo].[sp_getobjects]
AS
exec ('
select *
from [sys].[objects]
where is_ms_shipped = 0
order by type, name
')
go
use AdventureWorks2017
exec sp_getobjects
#LunchBox - it's your single stored procedure (that you create in one database) that is actually going to need to contain the "exec sp_MSforeach ...." command, and instead of the command to be executed being "EXEC ", it will need to be the actual SQL that you were going to put into the stored proc.
Eg. (inside your single stored procedure)
EXEC sp_MSforeachdb 'USE ?; SELECT * FROM <table>; UPDATE <another table> SET ...';
Think of the stored procedure (that you put into one database) as being no different than your Python code file - if you had actually wanted to achieve the same thing in Python, you would have either needed to create the stored proc in each database, or build the SQL statement string in Python and execute it against each database.
I understand what you thought you might be able to achieve with SQL, but stored procedures really don't work the way you were expecting. Even when you're in the context of a different database, but you run EXEC <different_db>.stored_proc, that stored proc ends up running in the context of the database in which it exists (not your context database).
Now, the only one issue you may come up against is that the standard sp_MSforeachdb stored proc has a limit of 2000 characters for the command that can be executed (although, it does have multiple "command" parameters, this may not be practical if you were planning on running a very large code block, perhaps with variables that carry all the way through). If this is something that might impact what you're intending to do, you could do a search online for "sp_MSforeachdb alternatives" - there seem to be a handful that people have created where the command parameter can contain a larger string.
I have a stored procedure that returns several tables (currently consumed by a web service). I now need to insert that output into a SQL Server database.
I can insert a single table if I know the existing definition via
INSERT INTO #temp
EXEC ('myProcSQlhere')
But for this I need to know the definition of the output table in advance.
SELECT *
INTO #temp
FROM OPENQUERY(SERVERNAME, 'EXEC myProcSQlhere')
Which gets around knowing the table definition, but only allows entry into one table. So how do I insert data into multiple tables?
A stored procedure can only return one value. What your stored procedure does is performing multiple selects and so giving multiple result sets. This works for systems that can consume multiple result sets but you are stuck in SQL-Server.
Check if the stored proc doesn't already call independent stored procedures for each result set and if so, call those. Or use the definition of the stored procedure and call each query used within sequentially.
If you have no access to the system providing the stored procedure, you will need to implement a CLR stored procedure and fetch each result set to store the results into different tables.
Should we end stored procedures with GO statement, if so what are the advantages of using GO?
CREATE PROCEDURE uspGetAddress #City nvarchar(30)
AS
SELECT *
FROM AdventureWorks.Person.Address
WHERE City = #City
GO
The statement go, per the documentation
Signals the end of a batch of Transact-SQL statements to the SQL Server utilities.
...
GO is not a Transact-SQL statement; it is a command recognized by the sqlcmd and osql
utilities and SQL Server Management Studio Code editor.
SQL Server utilities interpret GO as a signal that they should send the current batch
of Transact-SQL statements to an instance of SQL Server. The current batch of statements
is composed of all statements entered since the last GO, or since the start of the
ad-hoc session or script if this is the first GO.
A Transact-SQL statement cannot occupy the same line as a GO command. However, the line
can contain comments.
Users must follow the rules for batches. For example, any execution of a stored procedure
after the first statement in a batch must include the EXECUTE keyword. The scope of
local (user-defined) variables is limited to a batch, and cannot be referenced after a
GO command.
A stored procedure definition, per the documentation for create procedure, comes with restrictions. it must be the first (and only) statement in the batch:
The CREATE PROCEDURE statement cannot be combined with other Transact-SQL statements in
a single batch.
That means the body of stored procedure ends with the batch. Adding GO in your source file is good practice. Especially since it's common to do things prior to and following the creation of a stored procedure. You'll often see source files that look something like this:
if (object_id('dbo.foobar') is not null ) drop procedure dbo.foobar
GO
-- dbo.foobar --------------------------------------------
--
-- This stored procedure does amazing and wonderful things
----------------------------------------------------------
create procedure dbo.foobar
as
...
{a sequence of amazing and wonderful SQL statements}
...
return 0
GO
grant execute on dbo.foobar to some_schema
GO
And the value for GO is adjustable in Sql Server Management Studio's options. If you'd like to use something like jump instead of go, you can (bearing in mind that you're almost certainly going to give yourself grief in doing so.).
No, you should end your procedure with RETURN.
CREATE PROCEDURE uspGetAddress #City nvarchar(30)
AS
SELECT *
FROM AdventureWorks.Person.Address
WHERE City = #City
RETURN
The GO is really meant to separate commands in a sql script.
Just wanted to point out that without a GO at the end of your stored procedure, any T-SQL after the supposed end of the procedure body will still be included in the body of the proc.
For example
CREATE PROCEDURE Foo
BEGIN
SELECT * FROM dbo.Bar;
END
DROP TABLE dbo.Bar;
In this example, running EXEC dbo.Foo will end up dropping the table even though it is after the END. To avoid that, you need to place a GO after the END.
I prefer to surround the body of the stored procedure with begin and end statements:
CREATE PROCEDURE uspGetAddress (
#City nvarchar(30)
) AS
BEGIN
SELECT *
FROM AdventureWorks.Person.Address
WHERE City = #City;
END;
GO is a not a T-SQL command. It is understood by the tools that run scripts. As the documentation describes:
GO is not a Transact-SQL statement; it is a command recognized by the
sqlcmd and osql utilities and SQL Server Management Studio Code
editor.
SQL Server utilities interpret GO as a signal that they should send
the current batch of Transact-SQL statements to an instance of SQL
Server. The current batch of statements is composed of all statements
entered since the last GO, or since the start of the ad hoc session or
script if this is the first GO.
By the way, in your case, a user-defined table function might be more appropriate than a stored procedure.
I want to ask that which is a better way to insert/update/delete data in to database, to use queries directly from data-layer or create stored procedure for every inserting and deletion?
Your question depends entirely on the type of queries you're talking about.
For simple CRUD operations on a single table with no database-side rules that need to be followed, direct SELECT, UPDATE, or DELETE statements are fine.
For more complex operations, such as when your database applies normalization and access multiple tables, a stored procedure is worth the work. (In fact, "use stored procedures only when they're worth the extra work" is a good rule.)
For simple CRUD for multiple rows in a single query call, a program query is the only way to go unless you want to muck about with XML.
(And for simple CRUD where you're going to be using a recordset-aware interface, either should work just fine.)
i always used a Stored procedure to do simple CRUD operation
i used to do all CRUD operation within one SP, hope it will help.
For Example
create proc <procedure name>
(
<parameterName> <datatype>=<default value if any>,
#mode varchar(20)
)
as
begin
if(#mode='Insert')
begin
--your query for insert
end
if(#mode='Update')
begin
--your query for update
end
if(#mode='Delete')
begin
--your query for delete
end
if(#mode='Select')
begin
--your query for Select
end
end
you can have more "Mode" like 'select by id','soft delete','hard delete',etc...
I have a stored procedure, in one database within my SQL server, that sets permissions to all stored procedures at once for that particulat database. Is there a way to create this stored procedure in a way were I can call it easily from any database within the SQL server and if so how do I go about doing such a thing
While the best solution to this specific question of granting execute to all procedures is the one provided by marc_s, the actual question was is there a way to create a single stored procedure and make it available to all databases.
The way to do this is documented at https://nickstips.wordpress.com/2010/10/18/sql-making-a-stored-procedure-available-to-all-databases/:
Create the stored procedure in the master database.
It must be named to start with sp_, e.g. sp_MyCustomProcedure
Execute sys.sp_MS_marksystemobject passing the name of the procedure, e.g. EXEC sys.sp_MS_marksystemobject sp_MyCustomProcedure
Here is a simple example which just selects the name of the current database:
use master
go
create procedure dbo.sp_SelectCurrentDatabaseName as begin
select db_name()
end
go
execute sys.sp_MS_marksystemobject sp_SelectCurrentDatabaseName
go
Calling exec dbo.sp_SelectCurrentDatabaseName on any database will then work.
To mark the procedure as not a system object, there a some nasty hacks suggested at https://social.msdn.microsoft.com/Forums/sqlserver/en-US/793d0add-6fd9-43ea-88aa-c0b3b89b8d70/how-do-i-undo-spmsmarksystemobject?forum=sqltools but it is safest and easiest to just drop and re-create the procedure.
Caveat
Of course creating system procedures like this is breaking the common rule of not naming your own procedures as sp_xxx, due to the possibility of them conflicting with built-in procedures in future versions of SQL Server. Therefore this should be done with care and not just create a load of randomly named procedures which you find useful.
A common simple way to avoid this is to add your own company/personal prefix to the procedure which Microsoft is unlikely to use, e.g. sp_MyCompany_MyCustomProcedure.
I have a stored procedure, in one database within my SQL server, that
sets permissions to all stored procedures at once for that particular
database.
You could archive the same result much easier:
create a new role, e.g. db_executor
CREATE ROLE db_executor
grant that role execute permissions without specifying any objects:
GRANT EXECUTE TO db_executor
This role now has execute permissions on all stored procedures and functions - and it will even get the same permissions for any future stored procedure that you add to your database!
Just assign this role to the users you need and you're done....
Have you tried a 3 or 4 part name?
InstanceName.DatabaseName.dbo.usp_Name
That procedure could in turn reference objects in other databases using the same conventions. So you could parameterize the name of the database to be operated on and use dynamic SQL to generate 4 part names to reference objects such as system tables.