SQL Stored Procedure Best Practices

1. Establishing Structural Integrity and Modular Design Boundaries

When engineering database backends, it is highly tempting to treat stored procedures as dumping grounds for multi-thousand-line operational scripts.

The Single-Responsibility Rule

If a stored procedure is tasked with auditing a user session, calculating an inventory delta, updating a financial ledger, and sending out transactional metadata triggers all within a single code block, it is structurally flawed. Monolithic procedures are incredibly difficult for relational engines to optimize because the internal branches create highly unpredictable execution flows.

Instead, break your operations down into discrete, modular components. Have a parent orchestration procedure manage the transactional boundaries while calling specialized child procedures to handle specific sub-tasks. This clean separation of concerns ensures that engineering leads can isolate and troubleshoot bugs without risking regressions across unrelated business modules.

2. Advanced Parameter Engineering and Defending Against Side Effects

Parameters act as the contract between your calling application and the database engine. Crafting these interfaces requires precise syntax and strict data governance to ensure maximum execution stability.

Strict Data Type Matching

One of the most insidious performance killers in relational databases is an implicit data type conversion. If a table column is defined as a VARCHAR(50) and your stored procedure parameter is declared as an NVARCHAR(50), the database engine cannot directly compare the two strings. To resolve the conflict, the query optimizer must inject a hidden conversion operator into the execution plan, converting every single row in the column to match the parameter type.

This conversion mechanism strips the database engine of its ability to perform high-speed index seek operations, forcing a full table or clustered index scan instead. To prevent this, always cross-reference your database schema and guarantee that stored procedure input and output parameters mirror the exact data types, lengths, and collations of the underlying table columns they interact with.

The Strategic Value of Default Parameter Values

When designing robust software interfaces, resilience is paramount. Assigning sensible default values to parameters where applicable allows your stored procedures to gracefully handle omitted arguments from client applications. This practice simplifies API integration and ensures that non-critical parameters—such as sorting orders, page sizes, or optional filtering flags—have safe fallback metrics established directly within the database tier.

3. Designing Enterprise-Grade Error Handling and Transaction Controls

In a production environment, errors are an inevitability. How your database code responds to an unexpected failure separates amateur scripts from enterprise-grade software infrastructure.

Implementing Structured Error Trapping

Modern database engines provide robust error-trapping constructs through TRY...CATCH blocks. Every single stored procedure that alters data state must encapsulate its logic within a structured exception-handling framework. When an error occurs within the TRY block, control is immediately passed to the CATCH block, preventing unhandled exceptions from bubbling up to the client application in an unsafe state.

Defending Transactional Atomicity

When executing multi-statement modifications, safeguarding data integrity requires strict adherence to ACID principles (Atomicity, Consistency, Isolation, Durability). You must manage transactions explicitly, rather than relying on implicit server behaviors.

By checking the internal transaction state (XACT_STATE()) inside the CATCH block, you can safely determine if a transaction is uncommittable and roll it back cleanly. This deterministic error boundary prevents partial updates from corrupting your enterprise ledgers and keeps data blocks unlocked, eliminating cascading application timeouts.

4. Maximizing Execution Plan Reusability and Performance Stability

To build blazing-fast database routines, you must design your stored procedures to work seamlessly with the query optimizer’s caching mechanisms.

Leveraging Pre-Compiled Execution Plans

One of the primary structural advantages of using stored procedures over raw ad-hoc SQL queries is execution plan reuse. When a stored procedure executes for the first time, the database engine compiles an optimal path for retrieving data and caches it in the server’s memory buffer pool. Subsequent executions simply reuse this cached plan, eliminating compilation latency and drastically reducing CPU consumption across your database cluster.

Mitigating the Perils of Dynamic SQL

Injecting dynamic SQL strings inside a stored procedure via execution commands like EXEC() or EXECUTE IMMEDIATE breaks the core compilation benefits of stored procedures. The database engine treats raw dynamic strings as ad-hoc queries, requiring a fresh compilation plan nearly every time they execute. Furthermore, raw concatenation of dynamic strings opens a massive vector for catastrophic SQL Injection attacks.

If dynamic SQL is absolutely mandatory—such as for highly complex, multi-axis search screens—always implement it using parameterized execution commands like sp_executesql. This advanced routine allows the database engine to cache the underlying parameter structure securely, defending your infrastructure against malicious code injection while promoting efficient plan reusability.

5. Architectural Memory Governance: The Dangers of Row-by-Row Processing

Relational database engines are engineered from the ground up to process data in massive sets. Despite this fact, a common anti-pattern among application developers migrating to database environments is row-by-row procedural programming.

Eliminating Cursors and Loops

Using database cursors or WHILE loops to iterate through rows sequentially is one of the most resource-intensive operations you can write. A loop forces the database engine to perform individual memory fetches, context switches, and locking operations for every single record in the dataset. A cursor processing 100,000 rows will easily run orders of magnitude slower than a clean set-based query.

Always refactor procedural loops into declarative, set-based T-SQL logic utilizing standard relational operators such as JOIN, MERGE, and conditional CASE expressions. For instance, if a person encounters a legacy cursor designed to calculate tiered bulk discounts row-by-row, he can easily refactor that logic into a single, highly optimized UPDATE statement driven by an inner join to a reference matrix. This set-based optimization slashes execution times from hours to milliseconds.

6. Security Boundaries and Enforcing Minimum Privilege Access

Stored procedures serve as a vital security abstraction layer, serving as a firewall between external networks and your sensitive raw data storage tables.

Implementing Schema Abstraction

In a secure enterprise architecture, application service accounts must never be granted direct read or write access to physical database tables. If an application account possesses direct table permissions, a compromise of that account gives an attacker full access to manipulate or exfiltrate your entire corporate data footprint.

Instead, deny all direct table access and route every single data interaction through stored procedures. This approach allows security teams to grant application accounts explicit EXECUTE permissions exclusively on specific stored procedures. The application can query data and perform business actions only through these tightly governed gates, creating an immutable security perimeter around your core data infrastructure.

Using the WITH EXECUTE AS Clause Safely

By default, a stored procedure runs under the security context of the user calling it. However, scenarios arise where a standard user must perform an action that requires temporary elevated administrative privileges—such as writing to an audited security log table.

Utilizing the WITH EXECUTE AS clause allows you to explicitly define the execution context of the procedure, granting it the identity of a specific, highly restricted service principal during its lifecycle. This capability enables you to enforce the principle of least privilege, ensuring that application tiers can perform specialized tasks securely without expanding their global access footprint.

7. Operational Best Practices: Code Maintainability and Standards

To ensure your stored procedure libraries remain asset assets rather than technical debt as your engineering organization expands, adopt these industry-proven baseline standards:

• Enforce Clean Naming Conventions: Never prefix your custom stored procedures with sp_. The sp_ prefix is explicitly reserved by the database engine for system stored procedures. When the engine encounters a procedure starting with sp_, it is forced to scan the master database first, incurring unnecessary lookup overhead and introducing potential naming collisions during engine upgrades. Use clear, organizational prefixes such as App_, Core_, or Reporting_.
• Disable Unnecessary Metadata Counters: Always include the SET NOCOUNT ON; statement at the absolute top of your stored procedures. By default, the database engine transmits a network message back to the calling client indicating the exact number of rows affected by every statement within the procedure. In high-transaction environments, these metadata packets create substantial network chatter and can break application object-relational mappers (ORMs). Turning this off improves throughput.
• Avoid Star Selections (SELECT *): Never use wildcard selections inside production code. Explicitly declare every single column required by your query logic. This practice protects your stored procedures from breaking if a DBA adds, modifies, or drops non-related columns from the underlying tables in the future, while minimizing network and memory usage.
• Incorporate Comprehensive Code Headers: Every stored procedure must include a standardized documentation block at the top of the script detailing the author, creation date, modification history, and the business intent of the logic. This establishes clear accountability and speeds up onboarding for future development teams.

8. Summary and Conclusion

Adhering to SQL stored procedure best practices is a non-negotiable requirement for any serious database engineer or enterprise cloud architect aiming to build modern, performant, and secure data-delivery platforms.

By enforcing single-responsibility boundaries, matching data types rigorously, implementing deterministic transaction controls, and completely eliminating row-by-row processing, you empower your organization to process data with unparalleled speed and architectural stability.

You may also like the following articles:

• SQL Query Optimization Tips
• SQL Server Functions vs Stored Procedures
• Debug Stored Procedure In SSMS
• Get Stored Procedure List in SQL Server by Modified Date
• How to Insert Data Using Stored Procedure in SQL Server

Bijay Kumar Sahoo

After working for more than 15 years in the Software field, especially in Microsoft technologies, I have decided to share my expert knowledge of SQL Server. Check out all the SQL Server and related database tutorials I have shared here. Most of the readers are from countries like the United States of America, the United Kingdom, New Zealand, Australia, Canada, etc. I am also a Microsoft MVP. Check out more here.

sqlserverguides.com

Debug Stored Procedure In SSMS

Poorly debugged procedures lead to:

• Performance Drag: Logic loops that consume excessive CPU.
• Data Integrity Issues: Incorrect calculations that impact the bottom line.
• Scalability Bottlenecks: Code that works for ten rows but fails for ten million.

By mastering the debugger, you aren’t just fixing a bug; you are ensuring the reliability of the entire data pipeline.

The SSMS Debugging Toolkit: An Overview

Before we start the tutorial, let’s look at the tools at our disposal. Microsoft has evolved the debugging experience significantly, though it’s important to note where certain features reside.

Key Debugging Components

My Step-by-Step Tutorial: Debugging Your First Stored Procedure

Let’s walk through the exact process I use when a client, say a healthcare provider, tells me their “Patient Billing” procedure is returning null values.

Phase 1: Environment Preparation

You never, and I mean never, debug directly in a production environment.

1. Isolate the Environment: Ensure you are connected to a Development or UAT instance.
2. Permissions Check: Debugging requires the sysadmin fixed server role or specific permissions. I always ensure my account has the EXECUTE and VIEW DEFINITION rights, alongside being a member of the db_owner role in the test environment.
3. The “Driver” Script: Instead of just running the procedure, I write a “driver” script in a new query window. This script declares the variables, sets their values, and then calls the procedure.

Phase 2: Setting Breakpoints

Think of a breakpoint as a “stop sign” for your code.

• Find the line where you suspect the logic fails—perhaps a complex JOIN or a WHILE loop.
• Click the gray margin to the left of the line number. A red dot will appear.
• Pro Tip: I like to set breakpoints at the very beginning of the BEGIN...END block and right before the final SELECT or RETURN.

Phase 3: Launching the Debugger

In the toolbar, you’ll see the green “Play” button labeled Debug.

1. Click Debug (or press Alt + F5).
2. SSMS will switch to the Debugging Layout. If your windows (Locals, Watch, Call Stack) don’t appear, go to Debug > Windows to toggle them on.
3. The execution will pause at your first breakpoint, highlighted by a yellow arrow.

Phase 4: Navigating the Logic

This is where the real detective work happens. Use these keyboard shortcuts to move with authority:

• F11 (Step Into): Use this to follow the execution into a nested stored procedure or function.
• F10 (Step Over): Use this to execute the current line and move to the next without diving into sub-procedures.
• Shift + F11 (Step Out): Use this if you’ve stepped into a long function and want to jump back to the parent procedure.

Advanced Techniques: Beyond the Basics

Once you are comfortable with stepping through code, you need to use the more sophisticated windows to understand why the bug exists.

Monitoring State with the Locals Window

In the Locals Window, SSMS automatically lists every variable declared in your procedure and its current value. I watch this like a hawk. If a variable that should hold a “Customer ID” suddenly becomes NULL after a specific SELECT statement, I’ve found my culprit.

The Watch Window: Your Custom Dashboard

Sometimes the Locals window is too cluttered. I use the Watch Window to track specific expressions. For example, if I’m calculating sales tax for a project in Texas, I might add an expression like @SubTotal * 0.0825 to the Watch window to see how the value changes in real-time as the @SubTotal is updated.

Using the Call Stack for Nested Complexity

In large-scale US financial systems, it’s common for one procedure to call five others. The Call Stack is your map. It shows you the path the execution took to reach the current line. If an error occurs deep inside a “CalculateInterest” procedure, the Call Stack tells me exactly which “AccountProcess” call triggered it.

Troubleshooting Common Debugger Issues

Even for experts, the SSMS debugger can be finicky. Here are the three most common hurdles I encounter and how to clear them.

1. Firewall Blocks

Many U.S. corporate networks are locked down tight. The SSMS debugger uses RPC (Remote Procedure Call) ports. If you can’t start a session, your local Windows Firewall or the server’s firewall is likely blocking the connection.

• Fix: Work with your SysAdmin to ensure the necessary ports (typically TCP 135 and the dynamic range) are open between your workstation and the SQL Server.

2. “The debugger is not enabled”

Sometimes the debugger simply refuses to start.

• Fix: Ensure you are using a version of SSMS that matches or is newer than your SQL Server version. Also, verify that you aren’t trying to debug a script that isn’t a stored procedure (the debugger works best when wrapped in an EXEC statement).

3. Performance Overhead

Debugging is “heavy.” It places locks and consumes resources.

• Warning: Running the debugger on a busy server in a Chicago data center can cause “blocking” for other users. This is why isolation is your best friend.

The “Manual” Debugging Method (The DBA’s Secret)

Sometimes, the GUI debugger isn’t the right tool—especially if you are dealing with a “heisenbug” that only appears under heavy load. In these cases, I revert to Transaction-based Debugging.

The BEGIN TRAN Strategy

This is a high-authority move. I wrap my test execution in a transaction that I never commit.

1. BEGIN TRANSACTION
2. EXEC MyStoredProcedure @Param1 = 'USA'
3. SELECT * FROM TargetedTable -- Check the results
4. ROLLBACK TRANSACTION

By using ROLLBACK, I can see exactly what the procedure did to the data without actually making any permanent changes. This is the safest way to “debug” the results of a procedure.

Comparison: Debugger vs. PRINT vs. Extended Events

Expert Best Practices for Stored Procedures

To minimize the time you spend debugging, I recommend adopting these development standards used by top-tier US engineering teams:

• Use TRY...CATCH Blocks: Always wrap your logic. It allows you to catch errors gracefully and log them to a custom ErrorLog table.
• Set NOCOUNT ON: This prevents the “X rows affected” messages from interfering with your result sets, which can sometimes confuse debugging tools.
• Comment Your Logic: If you’re writing a 500-line procedure for a logistics firm in Atlanta, your future self will thank you for explaining why a specific WHERE clause exists.
• Modularize: Instead of one giant “God Procedure,” break logic into smaller, testable sub-procedures. It is much easier to debug a 20-line procedure than a 2000-line one.

Conclusion:

Debugging is more than just fixing errors; it’s about understanding the “soul” of your data engine. When you can step through a stored procedure in SSMS, monitor the call stack, and predict variable shifts before they happen, you stop being a coder and start being an architect.

You may also like the following articles:

• Trigger SQL Server

Bijay Kumar Sahoo

After working for more than 15 years in the Software field, especially in Microsoft technologies, I have decided to share my expert knowledge of SQL Server. Check out all the SQL Server and related database tutorials I have shared here. Most of the readers are from countries like the United States of America, the United Kingdom, New Zealand, Australia, Canada, etc. I am also a Microsoft MVP. Check out more here.

sqlserverguides.com

Whenever I am required to execute complex logic for many records in a table, I use the while loop to avoid writing this logic again and again; I encapsulate this logic into a stored procedure, so whenever I need it, I just call this procedure.

This reduces my time and effort. In this tutorial, I have explained the while loop and stored procedure and how you can encapsulate the while loop within the stored procedure for repetitive tasks or logic that you want to execute repeatedly.

You will learn this concept by applying it using real-world examples.

So, let’ start,

While Loop in SQL Server Stored Procedure

First, you must know what a while loop is and how it works. The while loop in SQL Server executes the block of code repeatedly based on the specified boolean condition.

The while loop runs until the boolean condition becomes false, and as soon as the boolean condition becomes false, the while loop is terminated.

The syntax is given below.

WHILE boolean_condition
BEGIN
    -- Statements that you want to execute
END

Where,

• boolean_condition: It is the expression that returns true or false. This condition is evaluated before starting the next iteration.
  • If the condition is true, then the block of statements within BEGIN and END is executed,
  • Otherwise, if the condition is false, it breaks the execution or exits the loop. If any code exists after the END keyword, it begins to execute that code.

The BEGIN…END section is where you write your SQL statement, query, or whatever operation you want to perform on the database.

Now that you know how to use the while loop, let’s learn about stored procedures. A stored procedure is a way to store the database logic that you want to execute repeatedly.

Suppose you have complex database logic that you need to execute usually, so instead of writing this logic whenever required, you keep the logic in something called stored procedure, then call this stored procedure whenever you need that logic.

If you have any doubts related to the stored procedure, then you can refresh your knowledge about the stored procedure by reading this tutorial, Create Stored Procedure in SQL Server.

Here, we will build a stored procedure to update the inventory, such as the product quantity. So whenever we need to update the product quantity, we will call this stored; that’s it.

First, create a table named Products with columns ID and Quantity which is shown below.

CREATE TABLE Products (
    ID INT PRIMARY KEY,
    Quantity INT
);

Insert the 10 different records into the table Products using the query below.

INSERT INTO Products (ID, Quantity) VALUES
(1, 100),
(2, 150),
(3, 200),
(4, 250),
(5, 300),
(6, 350),
(7, 400),
(8, 450),
(9, 500),
(10, 550);

View the Products table using the query below.

SLELECT * FROM Products;

From the above picture, you can see that the Products table contains the records of the 10 products and their quantities.

Now, suppose you need to create a stored procedure named UpdateInventoryQuantity. This stored procedure should contain a while loop to add the 10 quantities to each product.

You can create that kind of stored procedure using the command below.

CREATE PROCEDURE UpdateInventoryQuantity
AS
BEGIN
    DECLARE @ProductID INT = 1

    
    WHILE @ProductID IS NOT NULL
    BEGIN
       
        UPDATE Products
        SET Quantity = Quantity + 10
        WHERE ID = @ProductID

        SELECT @ProductID = MIN(ID) FROM Products WHERE ID > @ProductID
    END
END
GO

From the above output, you have successfully created the stored procedure containing the while loop to update the quantity of each product by 10 each time whenever you call this stored procedure.

Let’s understand the code part with BEGIN…END section.

This line DECLARE @ProductID INT = 1 creates a new variable named ProductID of type integer and initializes it with value 1.

Then, WHILE LOOP begins with boolean conditions @ProductID IS NOT NULL. This means the loop runs as long as ProductID is not equal to NULL. Meanwhile, it does the following things.

• It begins the update on the Products table using the ‘UPDATE Products’ statement and adds the 10 quantity to the value of the column ‘Quantity’ using the statement ‘SET Quantity = Quantity + 10’.
• It increases the quantity of the product where ID is equal to ProductID using the statement ‘WHERE ID = @ProductID’.

Then, the next line of code, ‘SELECT @ProductID = MIN(ID) FROM Products WHERE ID > @ProductID’, fetches the next ID of the product from the table and assigns this ID to the variable @ProductID.

But how does it fetch the ID of the next product? It does so by comparing the current ID with the next ID. If the next ID is greater than the current ID, it assigns it to the variable ProductID.

This is how the while loop with the stored procedure is used to update the quantity of the product.

To add the 10 quantities to each product, just call this procedure using the code below.

EXEC UpdateInventoryQuantity;

Look at the output; when you call the store procedure UpdateInventoryQuantity, it shows the number of rows updated, as you can see in the output.

Now, let’s check the Products table to see whether the quantity has increased by 10.

SELECT * FROM Products

From the output, you can see that each product quantity is increased by 10 if you compare it with the previous picture that is shown at the beginning of this tutorial while creating the table.

Well, from the above example, I hope that you understand how to use the while loop in stored procedure to perform repetitive operations on the database or table.

Conclusion

In this SQL Server tutorial, you learned about the while loop in the SQL Server store procedure. You covered the while loop and its syntax and also learned about the fundamental concept of a stored procedure.

Then, you learned how to use the while loop within the stored procedure by updating the product quantity by 10.

You may like to read:

• For Loop in SQL Server Stored Procedure
• How to use IF-ELSE in SQL Server Stored Procedure
• How to View Stored Procedures in SQL Server

Bijay Kumar Sahoo

After working for more than 15 years in the Software field, especially in Microsoft technologies, I have decided to share my expert knowledge of SQL Server. Check out all the SQL Server and related database tutorials I have shared here. Most of the readers are from countries like the United States of America, the United Kingdom, New Zealand, Australia, Canada, etc. I am also a Microsoft MVP. Check out more here.

sqlserverguides.com

While analysing the data, I needed to find the specific existence of the strings within the data containing strings. Actually, I needed to find the specific pattern of strings, so for that, I used the CHARINDEX() function.

Apart from the CHARINDEX() function, I have also explained more methods called PATINDEX() to find the string in the string, which is similar to the char index but provides more control over finding the string.

Let’s start,

SQL Server Find String in String

To find the string within a string, SQL Server has several functions such as CHARINDEX(), PATINDEX() and SUBSTRING().

Here, find string in string means find the substring in string, so you will learn how to find the specified substring in the given string. But you can also find a complete string in a string.

I will explain each of the functions to show you how to find a string in a string.

SQL Server Find String in String Using CHARINDEX

The CHARINDEX() function in SQL Server searches the specific part of a string within another string and returns the starting position of that specific string. Otherwise, it returns 0 if that specified string is not found.

The syntax is given on how to use the CHARINDEX() function.

CHARINDEX(substringToFind, stringToSearch, startingLocationForSearching)

Where,

• CHARINDEX(): A whole function returns the substring’s starting position.
• substringToFind: It is the substring or character expression whose starting position you want to know.
• stringToSearch: This is the source string that contains the substring that you want to find.
• startingLocationForSearching: The starting position where the search will start for the substring. If you forget to specify this option, the search begins by default from the beginning of the string.

If you want to know more about CHARINDEX() function, visit this tutorial CHARINDEX Function in SQL Server.

Let’s take an example and see.

First, create a table named Customers using the query below.

CREATE TABLE Customers (
    CustomerID INT,
    FirstName NVARCHAR(50),
    LastName NVARCHAR(50),
    Address NVARCHAR(255)
);

Insert the following records.

INSERT INTO Customers (CustomerID, FirstName, LastName, Address)
VALUES
(373275, 'Gabriel', 'Judy', '123 Main Boulevard'),
(377385, 'Joe', 'Isabella', '456 Oak St'),
(370795, 'Logan', 'Julia', '789 Pine Boulevard'),
(376977, 'Alan', 'Grace', '101 Maple Lane'),
(366868, 'Juan', 'Albert', '234 Elm Street'),
(376489, 'Willie', 'Elijah', '567 Birch Boulevard'),
(353230, 'Wayne', 'Randy', '890 Cedar Blvd'),
(351173, 'Amber', 'Denise', '321 Spruce Avenue'),
(348721, 'Danielle', 'Marilyn', '654 Ash Boulevard'),
(371731, 'Beverly', 'Gabriel', '987 Walnut Street');

Use the query below to view the Customers Table.

SELECT * FROM Customers;

Look at the above output, the table contains three columns FirstName, LastName and Customers.

Now, suppose you need to find customers whose addresses contain the word ‘Boulevard’; for that, you can use the CHARINDEX() method, as shown below.

SELECT FirstName, LastName, Address
FROM Customers
WHERE CHARINDEX('Boulevard', Address) > 0;

From the output, you can see there are 4 customers whose address contains the word ‘Boulevard’.

Here in the query part, CHARINDEX(‘Boulevard’, Address) > 0; takes the word ‘Boulevard’ that you want to find in the address (which is the string), and second, it takes that address (in which the specified string you want to find).

Then it compares the return result from 0. As you know, CHARINDEX returns the starting position of the substring in the string if it is found; otherwise, it returns 0, so check if the returned result is > 0.

From the output, you can see 4 customers whose addresses contain the word ‘Boulevard’ because the CHARINDEX() function returns non-zero for this word, which is greater than 0, and the given word exists.

So as a result, you get 4 customers with the address containing the word ‘Boulevard’

This is how to use the CHARINDEX() function to find the string in a string.

SQL Server Find String in String Using PATINDEX

The PATINDEX() function in SQL Server acts similarly to the CHARINDEX() function you learned in the above section, but it allows you to include pattern matching using wildcards.

So you can specify the string pattern that you want to find in the other string.

The syntax is given how to use the PATINDEX() method.

PATINDEX ( '%pattern%' , string_value )

Where,

• PATINDEX(): This is the function that returns the starting position of the pattern in the string.
• %pattern%: It is the character string or substring that you want to find in the string, and it should surrounded by %. Also, with the pattern, you can specify the wildcards as LIKE, such as:
  • Underscore (_) to match a single character.
  • Brackets [] to match any characters inside it.
  • [^] means do not match any character inside it.
  • % to match a string of any length.
• string_value: This is the source string where the starting position of the substring is found.

If you want to learn more about the PATINDEX() function, visit this tutorial PATINDEX Function in SQL Server.

Let’s take an example and understand how to use the PATINDEX() method to find a string in a string.

Take the same Customer table that you have created in the above section. And suppose you need to find the customers whose address contains the string or word ‘street’. For that, you can use the PATINDEX() here as shown below.

SELECT FirstName, LastName, Address
FROM Customers
WHERE PATINDEX('%Street', Address) > 0;

From the output, you can see that only two customers’ addresses contain the string ‘Street’.

Here, the query part PATINDEX(‘%Street’, Address) > 0; first takes the pattern ‘%Street’ that you want to find in the address, and second is the address (or string) where you want to find the given pattern (or substring).

This is how to use the PATINDEX() function in SQL Server to find the string in the string.

Conclusion

In this SQl Server tutorial, you learned about SQL Server find string in a string using the CHARINDEX() and PATINDEX() functions.

Additionally, you learnt about the syntax of both functions.

You may like to read:

• SQL Server Convert XML to String
• SQL Server Check If Column Exists
• How to Drop Table If Exists in SQL Server

Bijay Kumar Sahoo

After working for more than 15 years in the Software field, especially in Microsoft technologies, I have decided to share my expert knowledge of SQL Server. Check out all the SQL Server and related database tutorials I have shared here. Most of the readers are from countries like the United States of America, the United Kingdom, New Zealand, Australia, Canada, etc. I am also a Microsoft MVP. Check out more here.

sqlserverguides.com

First, I will introduce the syntax of the IF-ELSE in SQL Server. Then, with an example, you will learn how to use the if-else in the stored procedure.

You will create a stored procedure containing the if-else statement and execute the sql statement of the stored procedure based on the condition.

IF-ELSE in SQL Server Stored Procedure

To know how to use IF-ELSE in an SQL Server stored procedure, first, you must understand the if-else statement in SQL Server. This statement is used for conditional logic.

The syntax of the if-else is given below.

IF condition
	BEGIN
    	--  Write a SQL statemetn that is executed when condtion is true
	END
ELSE
	BEGIN
    	-- Write a SQL statemetn that is executed when condtion is false
	END

Where,

• IF condition: Here, IF is the keyword followed by the condition, which can be any expression that must evaluate to a true or false value (or boolean value).
• BEGIN and END: If the condition is true, then this section of IF is executed; otherwise, the ELSE section of the BEGIN…END block is executed. Remember, this section contains the SQL statement, query, or operation you want to execute based on the condition.

This is all about how you can use the if-else in the SQL Server, next let’s take an example where we will create stored procedure which contains the if-else statement.

I have the SalesTransactions table in the database’s Sales scheme, shown below.

Look at the data of the SalesTransactions in the above picture,

So here you have to create a stored procedure that takes the TransactionID as input, checks if the SaleAmount for the give transaction is greater than $100, if it is, the procedure computes the total amount including tax.

If the transaction is not greater than $100, it simply returns the SaleAmount without tax.

For that, you can look at the stored procedure ComputeTotalAmount.

CREATE PROCEDURE CalculateTotalAmount
	@TransactionID INT
AS
BEGIN
	DECLARE @SaleAmount DECIMAL(10, 2);
	DECLARE @TaxRate DECIMAL(5, 2);
	DECLARE @TotalAmount DECIMAL(10, 2);

	SELECT @SaleAmount = SaleAmount, @TaxRate = TaxRate
	FROM Sales.SalesTransactions
	WHERE TransactionID = @TransactionID

	IF @SaleAmount > 100
	BEGIN
    	SET @TotalAmount = @SaleAmount + (@SaleAmount * @TaxRate)
    	PRINT 'Total Amount including tax: ' + CAST(@TotalAmount AS VARCHAR)
	END
	ELSE
	BEGIN
    	PRINT 'Total Amount (no tax applied): ' + CAST(@SaleAmount AS VARCHAR)
	END
END

In the above-stored procedure, accept the TransactionID of tye INT as input and declare the three variables @SaleAmount, @TaxRate and @TotalAmount of type Decimal.

After that, a statement SELECT @SaleAmount = SaleAmount, @TaxRate = TaxRate FROM Sales.SalesTransactions WHERE TransactionID = @TransactionID retrieves the SaleAmount and TaxRat for the given TransactionID from the Sales.SalesTransactions table.

Then, the IF-ELSE checks if the SaleAmount is greater than $100. If true, it computes the total amount, including tax, and prints it. Otherwise, it prints the sale amount without adding tax in case of falsity.

Let’s check the stored procedure with TransactionID. For example, input the TransactionID as 1 to CalculateTotalAmount, as shown below.

EXEC CalculateTotalAmount 1;

Look at the output. When you pass the TransactionID as 1, the procedure returns the total amount as 100 without tax applied to it. That is because the IF condition becomes false in the Stored procedure, and it simply executes the ESLE block.

Now, let’s pass the different transaction IDs.

EXEC CalculateTotalAmount 2;

This time, when you pass the transaction as 2 it returns the total amount including the tax here IF condition becomes true because if you check the sale amount of given transaction ID in the database, which is $200.

The above is a simple example of an if-else statement in a stored procedure; you can even nest the if-else statement in the stored procedure.

Conclusion

In this SQL Server tutorial, you learned how to use IF-ELSE in SQL server stored procedure in this SQL Server tutorial.

Also learned the syntax of IF-ELSE statement, For example you created the CalculateTotalAmount stored procedure based on the provided TransactionID it executes the if-else block with procedure.

You may like to read:

• How to Delete Stored Procedures in SQL Server
• For Loop in SQL Server Stored Procedure
• Create Temp Table in SQL Server Stored Procedure

Bijay Kumar Sahoo

After working for more than 15 years in the Software field, especially in Microsoft technologies, I have decided to share my expert knowledge of SQL Server. Check out all the SQL Server and related database tutorials I have shared here. Most of the readers are from countries like the United States of America, the United Kingdom, New Zealand, Australia, Canada, etc. I am also a Microsoft MVP. Check out more here.

sqlserverguides.com

In this SQL Server tutorial, I will explain two methods for removing stored procedures from the database.

In the first method, you will use the SSMS to delete the stored procedures; in the second, you will use the query.

Let’s start,

Delete Stored Procedures in SQL Server

The command DELETE PROCEDURE can be used to delete stored procedures in SQL Server. You can also use the SQL Server Management Studio (SSMS) to remove the stored procedure in your database.

But why remove the stored procedure? Due to changes in the business logic, when you don’t need the stored procedure or replace it with new logic, you remove the stored procedure.

Let’s start,

Delete Stored Procedures in the SQL Server using SSMS

You delete stored procedures in SQL Server using the SQL Server Management Studio, a graphical user interface for managing SQL Server Database.

First, let me show you how to view all the stored procedures in your current database.

Open the SSMS, go to the left side of the Object Explorer, expand the Database folder, choose the database that contains the stored procedure, expand the Programmability subfolder, and finally expand the Stored Procedures subfolder, as shown below.

The subfolder Stored Procedures contains all the system—and user-created stored procedures; for example, store procedure dbo.uspCounter.

To delete this stored procedure, select and right-click on it, then select the Delete option, as shown in the below picture.

When you click the Delete option, it opens the Delete Object dialogue below.

To completely delete it, click the OK button at the bottom right of the dialogue box, as shown in the above output.

When you reopen the Stored Procedures subfolder, you won’t see the deleted stored procedure. In the picture below, the dbo.uspCounter is removed.

You don’t see any stored procedures with the name ‘dbo.uspCounter’ in the list because you deleted it.

This is how to Delete Stored Procedures in the SQL Server using SSMS.

Delete Stored Procedures in the SQL Server using Query

You just learned how to delete the stored procedure using the SSMS; here, you will learn how to remove the stored procedure using the command DROP PROCEDURE in SQL Server.

The syntax is given below.

DROP PROCEDURE name_of_procedure;

Where,

• DROP PROCEDURE: It is the command to delete the specified stored procedure.
• name_of_procedure: This represents the name of the stored procedure that you want to delete from the database.

First, execute the query below to list all the procedures stored in the current database.

SELECT name AS procedure_name
    , SCHEMA_NAME(schema_id) AS schema_name
    , type_desc
    , create_date
    , modify_date
FROM sys.procedures;

Let’s say you must delete the usp_GetEmployees stored procedure from the listed stored procedure. For that, you can use the DROP PROCEDURE command, as shown below.

DROP PROCEDURE usp_GetEmployees;

When you execute the above query, the specified stored procedure is deleted. So again, execute the below query to view all the procedures stored in the current database.

SELECT name AS procedure_name FROM sys.procedures;

From the output, you can see the stored procedure usp_GetEmployees doesn’t exist anymore cause it is deleted.

This is how to delete stored procedures in SQL Server using the query.

• Some practices that you must know before deleting any stored procedure.
• Always have a backup of the stored procedures before deletion.
• Ensure that the stored procedure you delete does not rely on other database objects, like triggers or other stored procedures.
• Use the transaction while deleting the stored procedures to prevent any partial changes in case any error occurs.
• Always keep track of the stored procedure you deleted and why you deleted it for future reference.

Conclusion

In this SQL Server tutorial, you learned how to delete stored procedures in SQL Server using the SSMS and query.

You learned step-by-step processes for removing stored procedures using SQL Server Management. Then, you used the DROP PROCEDURE command as a query to delete the stored procedure.

You may like to read:

• SQL Server Call Stored Procedure from another Stored Procedure
• How to Test Stored Procedures in SQL Server
• Rename Stored Procedure in SQL Server

Bijay Kumar Sahoo

After working for more than 15 years in the Software field, especially in Microsoft technologies, I have decided to share my expert knowledge of SQL Server. Check out all the SQL Server and related database tutorials I have shared here. Most of the readers are from countries like the United States of America, the United Kingdom, New Zealand, Australia, Canada, etc. I am also a Microsoft MVP. Check out more here.

sqlserverguides.com

As a database developer, if you are familiar with SQL Server, then you already know that SQL Server doesn’t have a FOR loop.

So, I will explain how you can simulate the FOR loop in the SQL Server stored procedure.

For Loop in SQL Server Stored Procedure

First, I want to say that SQL Server doesn’t have ‘FOR LOOP’, but you can achieve similar iterative processing using the ‘WHILE’ loop.

So, instead of ‘FOR LOOP’, you will use the ‘WHILE’ loop in the SQL Server stored procedure.

Let’s see the syntax of the WHILE loop, which is structured to repeatedly execute a block of statements as long as a specified condition is true.

WHILE [condition]
BEGIN
	-- SQL statements to execute
END

Where,

• WHILE: This is the beginning of the loop, and the loop continues as long as the condition specified next to ‘WHILE’ evaluates to ‘True’.
• condition: This is the boolean expression. If it is true, then the statement or logic within the loop is executed. If it becomes false, the loop ends, and control is passed to the next statement following the ‘END’ keyword.
• BEGIN…END: This is where all the statements that must be executed repeatedly are kept.

Let’s take an example of how to use the WHILE loop.

DECLARE @Count INT = 1;

WHILE @Count <= 5 
BEGIN
	PRINT 'Count is: ' + CAST(@Count AS VARCHAR); 
	SET @Count = @Count + 1; 
END

From the above output, you can see that the ‘WHILE’ loop prints the value of ‘@count’ and increments it by 1 in each iteration. The loop continues if ‘@Count’ is less than or equal to 5.

Let me explain what happens in detail; first, initialize the @Count variable of type INT with value 1.

Then, WHILE loop begins with condition @Count < 5, which means the loop runs as long as the value @count variable is less than 5.

Then, within the BEGIN and END block, the first statement PRINT ‘Count is: ‘ + CAST(@Count AS VARCHAR) prints the current value of counter variable @Count. After that, the next statement, SET @Count = @Count + 1, increases the current value of @Count by 1 at each iteration.

In each iteration, it prints the incremented value of the @Count variable that you can see in the output.

Now that you know how the WHILE loop works, it’s time to learn how to use it in the SQL Server stored procedure.

Before proceeding, if you don’t know how to create a stored procedure, then visit this tutorial Create Stored Procedure in SQL Server

Use the below command to create the uspCounter stored procedure, which prints the counter’s value five times, as shown below.

CREATE PROCEDURE uspCounter
AS
BEGIN
	DECLARE @Count INT = 1;

	WHILE @Count <= 5 
	BEGIN
		PRINT 'Count is: ' + CAST(@Count AS VARCHAR); 
		SET @Count = @Count + 1; 
	END;
END;

The ‘WHILE’ loop is used in the stored procedure uspCounter; this is the same one you learned. All you have to do is to place the while loop within the BEGIN and END blocks of the stored procedure.

This is how to use the WHILE loop in a stored procedure; as the FOR loop is not supported, you can use the WHILE loop to achieve the same task and functionality.

In the stored procedure, you can insert the records using the WHILE loop.

Conclusion

In this SQL Server tutorial, you learned how to use the FOR loop in the SQL Server stored procedure; in reality, you have used the WHILE loop instead of the FOR loop, which behaves similarly to the FOR loop.

You may like to read:

• Create Temp Table in SQL Server Stored Procedure
• How to View Stored Procedures in SQL Server
• How to Alter Stored Procedure in SQL Server

Bijay Kumar Sahoo

After working for more than 15 years in the Software field, especially in Microsoft technologies, I have decided to share my expert knowledge of SQL Server. Check out all the SQL Server and related database tutorials I have shared here. Most of the readers are from countries like the United States of America, the United Kingdom, New Zealand, Australia, Canada, etc. I am also a Microsoft MVP. Check out more here.

sqlserverguides.com

First, I will explain a temp table and its use in stored procedures. Then, with the example, you will understand how to use the CREATE TABLE command in the stored procedure to create a temp table.

Also, how to insert the data into the temp table, and finally, how to use the temp table in stored procedure to perform some operations.

Create Temp Table in SQL Server Stored Procedure

First, you must know what a temporary (temp) table in SQL Server is. The temp table is created at runtime to temporarily store the intermediate data while executing a SQL Script or stored procedure.

These tables don’t exist physically and are automatically deleted when the session ends. The user can also explicitly delete them. There are two kinds of temporary tables: local and global temp tables.

The local temp table is denoted by a single has symbol (#) and visible to the connection that creates them, and the global temp table is denoted by a double has symbol (##) and visible to all the connection

If you don’t know how to create a temporary table, follow this tutorial How to Create Temporary Table in SQL Server Management Studio?

But the question is, why use the temporary table in the stored procedure? There are several reasons: performance, organization, scope and cleanup, and debugging.

Now that you know about the temporary table and why you should use it in a stored procedure, let’s see how to create a temp table using the stored procedure.

I have a table of SalesTransactions in my database, shown below.

Using this table, you have to create a stored procedure CalculateTotalSaleIncludingTax. The task of this stored procedure is to take all the data of the SalesTransactions table and store it in the new table #SaleData, then compute the total sale amount, including the tax for each transaction.

Now look at the query below, which does the same task.

CREATE PROCEDURE CalculateTotalSaleIncludingTax
AS
BEGIN
    -- Create a temporary table to store sale data
    CREATE TABLE #SaleData (
        TransactionID INT,
        SaleAmount MONEY,
        TaxRate DECIMAL(5, 2)
    );

    -- Insert data into the temporary table
    INSERT INTO #SaleData (TransactionID, SaleAmount, TaxRate) 
	SELECT TransactionID, SaleAmount, TaxRate FROM Sales.SalesTransactions;

    -- Calculate total sale amount including tax for each transaction
    SELECT 
        TransactionID, 
        SaleAmount, 
        TaxRate, 
        SaleAmount + (SaleAmount * (TaxRate / 100.0)) AS TotalSaleIncludingTax
    FROM #SaleData
    ORDER BY TransactionID;
END

After executing the above command, a stored procedure, CalculateTotalSaleIncludingTax, is created. This procedure computes each transaction’s total sale amount, including tax.

Let us understand each statement with stored procedure.

CREATE TABLE #SaleData (
        TransactionID INT,
        SaleAmount MONEY,
        TaxRate DECIMAL(5, 2)
    );

This command creates a temp table named #SaleData with columns TansactionID, SaleAmount and TaxRate. This is where you must focus on defining the temp table in the stored procedure.

Next statement,

INSERT INTO #SaleData (TransactionID, SaleAmount, TaxRate) 
	SELECT TransactionID, SaleAmount, TaxRate FROM Sales.SalesTransactions;

This statement takes all the records from the SalesTransactions table and inserts them into temp table #SaleData.

The final statement,

SELECT 
        TransactionID, 
        SaleAmount, 
        TaxRate, 
        SaleAmount + (SaleAmount * (TaxRate / 100.0)) AS TotalSaleIncludingTax
    FROM #SaleData
    ORDER BY TransactionID;

This statement computes the total sale, including the tax for each transaction record. Here, the select command is called on the temp table #SaleData.

Now you know how the CalculateTotalSaleIncludingTax stored procedure works, execute this stored procedure.

EXEC CalculateTotalSaleIncludingTax;

The stored procedure returns the total sale amount, including the tax for each transaction ID.

Here, you have to focus on the part where the temporary table is created, data is inserted into that table with a stored procedure, and how to use the temporary table to perform some operations.

This is how you can create temp table in SQL Server stored procedure.

Conclusion

In this SQL Server tutorial, you learned how to create temp table in SQL Servers stored procedure.

Additionally, you learned how to perform some operations on the temp table using a stored procedure and retrieve the required information, such as total sales, including tax.

You may like to read:

• How to Create Index on Temp Table in SQL Server
• SQL Server Insert Into Temp Table
• Create SQL Server Stored Procedure Default Parameter
• How to Alter Stored Procedure in SQL Server
• How to View Stored Procedures in SQL Server

Bijay Kumar Sahoo

After working for more than 15 years in the Software field, especially in Microsoft technologies, I have decided to share my expert knowledge of SQL Server. Check out all the SQL Server and related database tutorials I have shared here. Most of the readers are from countries like the United States of America, the United Kingdom, New Zealand, Australia, Canada, etc. I am also a Microsoft MVP. Check out more here.

sqlserverguides.com

As a database developer, you must know how to view a stored procedure, which is helpful in many ways, such as debugging, optimizing, and understanding database schema.

So, here I will explain how to view stored procedures using SSMS and Query. You will learn how to view all the stored procedures in a specific database and also how to view the definition of stored procedures.

Let’s start,

How to View Stored Procedures in SQL Server

There are multiple ways to view stored procedures in SQL Server, and here I will show each way.

First is using the SQL Server Management Studio (SSMS); if you use the SSMS, you can easily view all the stored procedures in a specific database.

Open the SSMS and connect the SQL Server instance, and then you will see the window interface as shown below.

Now, if you look at the left side of the window, there is Object Explorer. In this explorer, expand the Databases folder, and then within that, you will see all the user-created databases, for example, Data and e-commerce, in the above picture.

As you know, stored procedures are stored in specific databases, so here, understand that you have created a stored procedure under the e-commerce databases, so expand this database as shown below.

After expanding the e-commerce databases, you see the different subfolders within it, so your stored procedure exists in the Programmability subfolder, as you can see in the above picture.

To view the stored procedure, explore the Programmability subfolder as shown below.

When you expand the subfolder Programmability, you again see several subfolders; your stored procedures are stored in the subfolder Stored Procedures, as you can see in the above picture.

To view all the stored procedures of the ecommerce database, expand the subfolder Stored Procedures as shown below.

Look, the subfolder stored procedures contains two kinds of stored procedures. The first is the system stored procedure in the subfolder System Stored Procedures, and the second is the created stored procedure you can see like dbo.ProcessOrder etc.

This is how to view the stored procedures in SQL Server using the SQL Server Management Studio.

How to View Stored Procedures in SQL Server through Query

From the above section, you learned how to view stored procedures using the SSMS; here, I will show how to do the same using the query.

So, here, multiple ways exist to view stored procedures in SQL Server through query.

First, open your computer’s query editor or SQL server command prompt, where you can execute the SQL Server query.

View Stored Procedures in SQL Server through Query using sp_helptext

There is a system-stored procedure called sp_helptext, which can help you view the stored procedures. This will not list all the stored procedures. Instead, you can use it to view specific stored procedures.

For example, the ecommerce database contains the ProcessOrder stored procedure. You can view it using the sp_helptext system procedure, as shown below.

EXEC sp_helptext ProcessOrder;

It shows all the statements or how the ProcessOrder stored procedure is created. Well, this sp_helptext is used to view the created stored procedure. Generally, it shows the script of the specified stored procedures.

This is how to view stored procedures in SQL Server through query using sp_helptext.

View Stored Procedures in SQL Server through Query using sys.sql_modules

Next is the sys.sql_modules system view, which contains a row for each object implemented as an SQL module, including stored procedures.

Use the below query to view all the stored procedures in the current database.

SELECT m.definition
FROM sys.sql_modules m
JOIN sys.objects o ON m.object_id = o.object_id
WHERE o.type = 'P'

Look, it returns all the stored procedures in the current database but as definition. This is how you can view all the stored procedures in the current database and the specified stored procedure definition.

Use the below query to view the ProcessOrder stored procedure definition.

SELECT m.definition
FROM sys.sql_modules m
JOIN sys.objects o ON m.object_id = o.object_id
WHERE o.type = 'P' AND o.name = 'ProcessOrder';

From the output, as you can see, the sys.sql_modules view allows us to view the complete definition of the specified stored procedure.

This is how to view stored procedures in SQL Server through query using the sys.sql_modules system view.

View Stored Procedures in SQL Server through Query using INFORMATION_SCHEMA.ROUTINES

The SQL Server has another view called INFORMATION_SHCEMA.ROUTINES contain information about all the stored procedures.

To view all the stored procedures, execute the below query.

SELECT ROUTINE_NAME, ROUTINE_DEFINITION
FROM INFORMATION_SCHEMA.ROUTINES
WHERE ROUTINE_TYPE = 'PROCEDURE';

Now, it is the INFORMATION_SCHEMA.ROUTINES all the stored procedures in the current database that you can see in the query output; look at the column ROUTINE_NAME, which contains procedure names such as usp_GetEmployees, ProcessOrder, etc.

Also, you can view the specified stored procedure using the query below.

SELECT ROUTINE_NAME, ROUTINE_DEFINITION
FROM INFORMATION_SCHEMA.ROUTINES
WHERE ROUTINE_TYPE = 'PROCEDURE' AND ROUTINE_NAME = 'UpdateEmployeeDetails';

So, it returned the two columns, ROUTINE_NAME and ROUTINE_DEFINITION, which contain the stored procedure name and its definition, respectively.

This is how to view stored procedures in SQL Server through query using INFORMATION_SCHEMA.ROUTINES view.

View Stored Procedures in SQL Server through Query using OBJECT_DEFINTION

SQL Server has a function called OBJECT_DEFINTION, which returns the SQL source text of the stored procedure if you know the object ID.

Same as sp_helptext, it returns the script of the stored procedure.

SELECT OBJECT_DEFINITION(OBJECT_ID('ProcessOrder'));

The output returns the definition or script of the ProcesOrder stored procedure. Here, you have to pass the stored procedure name to OBJECT_ID(), which receives the object ID of the specified stored procedure.

Then, this returned object is passed to the OBJECT_DEFINITION() function to view them. That is why the OJBECT_ID() function is passed to the OBJECT_DEFINITION() function.

This is how to view a specific definition of stored procedure in SQL Server.

I hope you understand how to find the stored procedure and its definition in SQL Server.

Conclusion

You learned to view stored procedures in SQL Server using the SSMS and Query.

Where you have used the different stored procedures and functions to view the stored procedure, you also learned to view a specific stored procedure using the sp_helptext and OBJECT_DEFINTION().

You may like to read:

• How to Alter Stored Procedure in SQL Server
• Create SQL Server Stored Procedure Default Parameter
• SQL Server Call Stored Procedure from another Stored Procedure

Bijay Kumar Sahoo

After working for more than 15 years in the Software field, especially in Microsoft technologies, I have decided to share my expert knowledge of SQL Server. Check out all the SQL Server and related database tutorials I have shared here. Most of the readers are from countries like the United States of America, the United Kingdom, New Zealand, Australia, Canada, etc. I am also a Microsoft MVP. Check out more here.

sqlserverguides.com

As a Database developer, administrator, etc., you should know how to modify the existing stored procedure.

I will start by explaining why to change the existing stored procedure, then the syntax you can use to modify the stored procedure.

Here, I will explain two types of syntax: one that allows you to modify the stored procedure of existing public schema and the other that will enable you to modify the stored procedure of specific schema.

Finally, with examples, you will see how to create and alter or modify the stored procedure in a specific schema.

Alter Stored Procedure in SQL Server

As you know, the stored procedure contains the set of logic or operations, and you can reuse the stored procedure anywhere or wherever it is required.

Sometimes, requirements arise due to changes in the business, so in that situation, you also need to change some existing stored procedures. So SQL Server provides ALTER PROCEDURE command to modify the existing stored procedure without dropping or recreating them.

The syntax is given below.

ALTER PROCEDURE procedure_name [ @parameter data_type ]
    [ WITH { RECOMPILE | ENCRYPTION | RECOMPILE, ENCRYPTION } ]
AS
BEGIN
    -- SQL statements to define the procedure logic
END

Where,

• ALTER PROCEDURE: It is the command to modify the specific stored procedure.
• procedure_name: Name of the stored procedure that you want to modify.
• @parameter data_type: It is the parameter and its data type that the stored procedure will accept, but it is optional.
• WITH RECOMPILE: Using this forces the procedure to compile at runtime, which is beneficial for those not executed continually.
• WITH ENCRIPTION: If you use this, it encrypts the contents of the procedure in the database, which doesn’t allow the user to view its logic.

Also, look at the syntax below if you have stored a procedure in a specific scheme, then use the syntax below to alter that stored procedure.

ALTER PROCEDURE schema_name.procedure_name [ @parameter data_type ]
    [ WITH { RECOMPILE | ENCRYPTION | RECOMPILE, ENCRYPTION } ]
AS
BEGIN
    -- SQL statements to define the procedure logic
END

Here, you need to make small changes; prefix the procedure_name with schema_name, such as schema_name.procedure_name.

Let’s take an example and see how to create and alter the stored procedure.

Creating Stored Procedure

So here, I have the Employees table, shown below.

Now, create a stored procedure named GetEmployeesOnSalary; this procedure will return the EmployeesID of the employees whose salary is greater than a certain amount.

CREATE PROCEDURE GetEmployeesOnSalary (@salary INT)
AS
BEGIN
	SELECT EmployeeID FROM Employees 
	WHERE Salary > @salary;
END;

Executing the above query creates a new stored procedure, GetEmployeesOnSalary, in your database.

Let’s check this procedure or execute it with a value equal to 60000 to check the employees whose salary exceeds 60000.

EXEC GetEmployeesOnSalary 60000;

When you execute the GetEmployeesOnSalary with a value of 60000, it returns all the employees whose salaries are greater than 60000 dollars.

Let’s say you have a task where you must include an employee’s name. That means you have to alter the procedure so that it should also return the employee with their name. Here, you can use the ALTER PROCEDURE command to modify the procedure.

ALTER PROCEDURE GetEmployeesOnSalary (@salary INT)
AS
BEGIN
	SELECT EmployeeID, Name FROM Employees 
	WHERE Salary > @salary;
END;

When you run the above query, it modifies the GetEmployeesOnSalary to include the ‘Name’ column in the SELECT statement without dropping and recreating the procedure.

Now, let’s execute the stored procedure again with the value 65000, as shown below.

EXEC GetEmployeesOnSalary 65000;

As you have modified the procedure, it returns the result in the same way as it also includes the employee name whose salary is greater than 65000 dollars.

Here, you have modified the stored procedure to add the column, but you can even add an additional parameter, logic, etc, to the stored procedure. It depends on what kind of modification you want.

Alter Stored Procedure in SQL Server of Specific Schema

Here, I will demonstrate how to alter the stored procedure in the specified schema in your database.

For example, there is a table SalesTransaction in the schema Sales, as shown below.

As you can see, the SalesTransaction table exists in the Sales schema; let’s create a stored procedure that will return the sale amount based on the specified TaxRate.

CREATE PROCEDURE Sales.GetTransactioOnTaxRate (@taxrate NUMERIC(10,2))
AS
BEGIN
	SELECT SaleAmount FROM Sales.SalesTransactions 
	WHERE TaxRate = @taxrate;
END;

When you execute the above command, it creates a new stored procedure, GetTransactioOnTaxRate, in the schema Sales of the current database.

Let’s execute the stored procedure with a tax rate value 5.0, as shown below.

EXEC Sales.GetTransactioOnTaxRate 5.0;

As you can see, it returns the sale amount of the transaction based on the tax rate 5.0. But as you can see, it is not meaningful, which means which transaction this sale amount belongs to.

So here, you have been assigned a task to alter the stored procedure GetTransactioOnTaxRate to include the transaction ID. Use the below command to modify the stored procedure.

ALTER PROCEDURE Sales.GetTransactioOnTaxRate (@taxrate NUMERIC(10,2))
AS
BEGIN
	SELECT TransactionID, SaleAmount FROM Sales.SalesTransactions 
	WHERE TaxRate = @taxrate;
END;

After executing the above command, it modifies the Sales.GetTransactioOnTaxRate to include the ‘TransactionID’ column in the SELECT statement without dropping and recreating the procedure.

Here, you can see the statement ALTER PROCEDURE Sales.GetTransactioOnTaxRate, altering the stored procedure GetTransactioOnTaxRate of the Sales schema.

Now execute the modified stored procedure with a tax rate of 8.0, as shown below.

EXEC Sales.GetTransactioOnTaxRate 8.0;

From the output, it included the transaction ID with the sale amount of the specified text rate value.

This is how you can alter stored procedures in SQL Server. I hope you now understand how to modify the stored procedure.

Conclusion

You learned how to alter stored procedure in SQL Server, where you have used the ALTER PROCEDURE command to modify the stored procedure.

Especially you learned how to include a column in the SELECT statement within the stored procedure, but you can modify the procedure name, logic, etc., using the ALTER PROCEDURE command.

You learned how to create and modify the stored procedure in the public and specific database schema.

You may like to read:

• Create SQL Server Stored Procedure Default Parameter
• SQL Server Call Stored Procedure from another Stored Procedure
• How to Test Stored Procedures in SQL Server

Bijay Kumar Sahoo

After working for more than 15 years in the Software field, especially in Microsoft technologies, I have decided to share my expert knowledge of SQL Server. Check out all the SQL Server and related database tutorials I have shared here. Most of the readers are from countries like the United States of America, the United Kingdom, New Zealand, Australia, Canada, etc. I am also a Microsoft MVP. Check out more here.

sqlserverguides.com