The Microsoft platform includes everything a business needs to develop and deploy a Web service-connected IT architecture: servers to host Web services, development tools to create them, applications to use them, and a worldwide network of more than 35,000 Microsoft Certified Partner organizations to provide any help you need.

[edit] Pre-compilation of SQL statements
SQL statements implemented as stored procedures in some cases run faster, as they can be pre-compiled. Execution plans for compiled statements can be stored in the database, together with the procedure. This can remove the compilation overhead that is typically required in situations where software applications send inline SQL queries to a database. However, most database systems implement statement caches to avoid repetitive compilation of dynamic SQL statements.

In addition, pre-compiled SQL statements, while avoiding some overhead, add to the complexity of creating an optimal execution plan because not all arguments of the SQL statement are supplied at compile time. Depending on the specific database implementation and configuration, mixed performance results will be seen from stored procedures versus generic queries or user defined functions .

[edit] Execution on a database server
Stored procedures can run directly within the database engine. In a production system, this typically means that the procedures run entirely on a specialized database server, which has direct access to the data being accessed. The benefit here is that network communication costs can be avoided completely. This becomes particularly important for complex series of SQL statements.

However, note that unnecessary or excessive procedural statement execution in the database server (typically a singular shared resource) may impair overall enterprise system performance – i.e., while application servers can often be dramatically scaled horizontally for increased processing capacity, the same is not generally or as easily accomplished for database servers.

Therefore, a growing school of thought (not among old school DBAs of course) advocates the database be used for what it’s best at – i.e., a very efficient file cabinet. Thereby restricting any database-local procedural executions to only very specific cases rather than the old school ubiquity – instead advocating the use of advanced object oriented domain class ontologies and reusable parameterized SQL generation.

However, the culture war on this point is likely to continue for years more!

[edit] Simplification of data management
Stored procedures allow for business logic to be embedded as an API in the database, which can simplify data management and reduce the need to encode the logic elsewhere in client programs. This may result in a lesser likelihood of data becoming corrupted through the use of faulty client programs. Thus, the database system can ensure data integrity and consistency with the help of stored procedures.

Some critics claim that databases should be for storing data only, and that business logic should only be implemented by writing a business layer of code, through which client applications should access the data. However, the use of stored procedures does not preclude the use of a business layer.

[edit] Security
Carefully written stored procedures may allow for fine grained security permissions to be applied to a database. For example, client programs might be restricted from accessing the database via any means except those that are provided by the available stored procedures.

[edit] Other uses
In some systems, stored procedures can be used to control transaction management; in others, stored procedures run inside a transaction such that transactions are effectively transparent to them. Stored procedures can also be invoked from a database trigger or a condition handler. For example, a stored procedure may be triggered by an insert on a specific table, or update of a specific field in a table, and the code inside the stored procedure would be executed. Writing stored procedures as condition handlers also allow DBAs to track errors in the system with greater detail by using stored procedures to catch the errors and record some audit information in the database or an external resource like a file.

Typical uses for stored procedures include data validation (integrated into the database) or access control mechanisms. Furthermore, stored procedures are used to consolidate and centralize logic that was originally implemented in applications. Large or complex processing that might require the execution of several SQL statements is moved into stored procedures and all applications call the procedures only.

Stored procedures are similar to user-defined functions (UDFs). The major difference is that UDFs can be used like any other expression within SQL statements, whereas stored procedures must be invoked using the CALL statement

There are times, however, when I need to issue a series of atomic statements but I don’t know what statements will need to be executed, exactly, until runtime. Or, there may be a variable number of stored procedure calls that need to be made based on data supplied by the user. For example, imagine that I presented a list of all departments in the system using a CheckBoxList Web control, allowing the user to select the set of departments she wanted to delete.

Upon posting back, I’d enumerate the items in the CheckBoxList’s Items collection and issue a call to the DeleteDepartment stored procedure we examined above. Now, deleting each department and its associated employees is treated as a transaction (as we have BEGIN TRANSACTION in the stored procedure), but I want all department deletions to behave as an atomic statement. That is, say the user opted to delete five departments. If three departments and their employees to be deleted only to have an error crop up when trying to delete the fourth department, I want to make sure that the delete of the first three departments and employees are “undone.” I can accomplish this by wrapping the loop through the Items collection and the subsequent calls to DeleteDepartment within a transaction itself. (This is an example of providing transactions at both the ADO.NET level and stored procedure level!)

That is, my code would look something like:

‘Create a connection
Dim myConnection As New SqlConnection(myConnString)
myConnection.Open()

‘Start the transaction
Dim myTrans As SqlTransaction = myConnection.BeginTransaction()

Dim sql as String = “DeleteDepartment”

Try
‘Create the SqlCommand object, specifying the transaction through
‘the constructor (along with the SQL string and SqlConnection)
Dim myCommand as New SqlCommand(sql, myConnection, myTrans)

For Each dept as ListItem in CheckBoxListID.Items
‘Add the dept.Value to the Parameters collection
myCommand.Parameters.Clear()

myCommand.Parameters.Add(“@DepartmentID”, dept.Value)

myCommand.ExecuteNonQuery()
Next

‘If we reach here, all command succeeded, so commit the transaction
myTrans.Commit

Catch ex as Exception
‘Something went wrong, so rollback the transaction
myTrans.Rollback()

Throw ‘Bubble up the exception
Finally
myConnection.Close() ‘Finally, close the connection
End Try

CREATE PROCEDURE DeleteDepartment
(
@DepartmentID int
)
AS

– This sproc performs two DELETEs. First it deletes all of the
– department’s associated employees. Next, it deletes the department.

– STEP 1: Start the transaction
BEGIN TRANSACTION

– STEP 2 & 3: Issue the DELETE statements, checking @@ERROR after each statement
DELETE FROM Employees
WHERE DepartmentID = @DepartmentID

– Rollback the transaction if there were any errors
IF @@ERROR 0
BEGIN
— Rollback the transaction
ROLLBACK

— Raise an error and return
RAISERROR (‘Error in deleting employees in DeleteDepartment.’, 16, 1)
RETURN
END

DELETE FROM Departments
WHERE DepartmentID = @DepartmentID

– Rollback the transaction if there were any errors
IF @@ERROR 0
BEGIN
— Rollback the transaction
ROLLBACK

— Raise an error and return
RAISERROR (‘Error in deleting department in DeleteDepartment.’, 16, 1)
RETURN
END

– STEP 4: If we reach this point, the commands completed successfully
– Commit the transaction….
COMMIT