Upgrading stored procedures in SQL Server 2005

Let's say you have a front-end application that's being written or managed by a different team and it isn't upgraded as often as the back-end database. You still want to make changes in your SQL Server application's stored procedures to take advantage of newer features. You also want to do this as gracefully as possible so the database and front-end application don't have a falling out.

For example, you may want to update a stored procedure to use some new functions available to T-SQL in SQL Server 2005, such as the TRY and CATCH functions, which make sophisticated error trapping a lot easier. You'd normally copy the existing stored procedure into a new, parallel stored procedure, update it to use the new functions and then test the behavior of the two side-by-side through either a modified version of the front-end application (if it's available) or Query Analyzer.

When you're confident the new stored procedure is behaving as it should and it is ready to be used in production, you can swap it in seamlessly either by renaming the two stored procedures or by copying in the code. I personally prefer doing a rename, since that allows you to have a backup copy of the old code -- backed up with your database like everything else in case you run into an unexpected wrinkle.

This...

Digg This!     StumbleUpon     Del.icio.us

RELATED CONTENT Database Development Using DELETE and TRUNCATE TABLE statements to delete data in SQL Server Speed up reports in SQL Server Reporting Services with caching Data Transformation Services vs. SSIS: The key differences Working with IntelliSense in SQL Server 2008 Management Studio Top tips and tricks for SQL Server database development Managing the development lifecycle with Visual Studio Team System 2008 Processing XML files with SQL Server functions A first look at Visual Studio Team System 2008 Database Edition How to create a SQL inner join and outer join: Basics to get started New datetime data types in SQL Server 2008 offer flexibility SQL Server Stored Procedures SQL Server Mailbag: CALs, witnesses and unwanted changes SQL Server Mailbag: Stored procedures, triggers and SSRS reports Top tips and tricks for SQL Server database development Top 10 SQL Server development tips of 2008 SQL Server trigger vs. stored procedure to receive data notification SQL Server errors, failures and other problems fixed from the trenches SQL Server and data manipulation in T-SQL How to use SQL Server 2008 hierarchyid data type SQL Server stored procedures tutorial: Write, tune and get examples Check SQL Server database and log file size with this stored procedure Microsoft SQL Server 2005 End of life comes for SQL Server 2005 SP2, 2008 SQL Server Reporting Services Fast Guide SQL Server Service Broker Tutorial and Reference Guide Tips for tuning SQL Server 2005 to improve reporting performance SQL Server consolidation: Why it's an optimization technique Parent-child dimensions in SQL Server 2005 with Analysis Services MDX Enforcing data integrity in a SQL Server database SSIS error message due to installation problem on SQL Server 2005 Should you upgrade to SQL Server 2005 or SQL Server 2008? Basics for working with DATETIME and SMALLDATETIME in SQL Server 2005 Microsoft SQL Server 2005 Research

RELATED GLOSSARY TERMS Terms from Whatis.com − the technology online dictionary library  (SearchSQLServer.com) trigger  (SearchSQLServer.com)

RELATED RESOURCES 2020software.com, trial software downloads for accounting software, ERP software, CRM software and business software systems Search Bitpipe.com for the latest white papers and business webcasts Whatis.com, the online computer dictionary

is a fairly standard technique, but one of the more interesting wrinkles I've seen on it involves the passing of an optional parameter:

There is another useful way to selectively test the code. Existing front-end calls to the stored procedure will not use the optional parameter and will execute old code. You can test the stored procedure in place using new front-end code and then gracefully upgrade existing references to the stored procedure as you go. Since the parameter is optional all the existing calls to the stored procedure (i.e., those without the parameter) will go through exactly as before.

If you aren't allowed to add new stored procedures but are allowed to modify existing ones, this is a good way to work around such a limitation. When no legacy code remains, you can then phase out the IF in the stored procedure. Lastly, deprecate the optional parameter in both the stored procedure and your front-end code.

About the author: Serdar Yegulalp is editor of the Windows Power Users Newsletter. Check it out for the latest advice and musings on the world of Windows network administrators -- and please share your thoughts as well!

More information from SearchSQLServer.com