Manage Learn to apply best practices and optimize your operations.

Upgrading stored procedures in SQL Server 2005

Learn how to upgrade your stored procedures to take advantage of new SQL Server 2005 features without breaking existing functionality. Contributor Serdar Yegulalp explains how in the second part of his backward compatibility series.

I recently explained how changes in SQL Server 2005 may break older applications and databases, especially where...

deprecated functions are used. Now I'm going to discuss how to use stored procedures in your migrated databases to take advantage of newer functionality in SQL Server 2005 without breaking existing functionality.

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 is a fairly standard technique, but one of the more interesting wrinkles I've seen on it involves the passing of an optional parameter:


{other parameters go here},
@optionalparameter Boolean=FALSE


If @optionalparameter=TRUE
 {NEW version of stored procedure with SQL Server 2005-specific commands goes here}
 {OLD version of stored procedure goes here}
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

  • Tip: Tuning stored procedures: Structured exception handling in SQL Server 2005
  • Tip: SQL Profiler: Features, functions and setup in SQL Server 2005
  • SQL Server Clinic: T-SQL performance problems and solutions

  • This was last published in June 2006

    Dig Deeper on Microsoft SQL Server 2005

    Start the conversation

    Send me notifications when other members comment.

    By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

    Please create a username to comment.