Reviewing deprecated SP's

Over the wend I was going through the SQL Server and our two most
commonly used applications looking for stuff to deprecate for removal.
Apparently, someone else did something similar. I found a whole fistful of
stored procedures that go like this:
CREATE PROCEDURE dbo.SomeProc
AS
/*
page after page after page of actual code
*/
GO
Since it was over the wend (no users), I was just going to make a list of
old SP's, grep the application code and if no matches found, rename them to
_SomeProc and then retest the apps to see what breaks.
But it would seem to me that leaving the SP in the database, but commenting
all the code in it is just plain stupid.
How do you folks apply best practices for deprecating old SP's, UDF's &
Views?
Peace & happy computing,
Mike Labosh, MCSD
"When you kill a man, you're a murderer.
Kill many, and you're a conqueror.
Kill them all and you're a god." -- Dave Mustane> But it would seem to me that leaving the SP in the database, but
> commenting all the code in it is just plain stupid.
Ditto. And dangerous too.

> How do you folks apply best practices for deprecating old SP's, UDF's &
> Views?
An important configuration management practice is keeping all DDL under
source control. I would create a script that drops all unneeded objects,
run it against a test database and then test the application. Once testing
is done, run the same script in production. If you find during your testing
that an object is actually needed, you can recreate it in your test database
using you source-controlled DDL.
Hope this helps.
Dan Guzman
SQL Server MVP
"Mike Labosh" <mlabosh@.hotmail.com> wrote in message
news:%23FjWphz$FHA.3048@.TK2MSFTNGP15.phx.gbl...
> Over the wend I was going through the SQL Server and our two most
> commonly used applications looking for stuff to deprecate for removal.
> Apparently, someone else did something similar. I found a whole fistful
> of stored procedures that go like this:
> CREATE PROCEDURE dbo.SomeProc
> AS
> /*
> page after page after page of actual code
> */
> GO
> Since it was over the wend (no users), I was just going to make a list
> of old SP's, grep the application code and if no matches found, rename
> them to _SomeProc and then retest the apps to see what breaks.
> But it would seem to me that leaving the SP in the database, but
> commenting all the code in it is just plain stupid.
> How do you folks apply best practices for deprecating old SP's, UDF's &
> Views?
> --
> Peace & happy computing,
> Mike Labosh, MCSD
> "When you kill a man, you're a murderer.
> Kill many, and you're a conqueror.
> Kill them all and you're a god." -- Dave Mustane
>|||I keep a collection af all objects that are actually used in a safe place, s
o
that when in doubt I can just drop all that actually exist and create those
that actually should.
Since it has always been my strong belief that true team work is based on
communication, and good development practices include efficient housekeeping
,
this drop/create method can also be used to s out 'suspect' team members.
;) After that there's just the matter of making them follow you into the bac
k
alley...
Jokes aside, the "if it ain't in SourceSafe, then it ain't used" rule makes
everybody's life a lot easier. However, if the rule is being introduced into
an existing and somewhat problematic environment, then renaming objects will
help ease into the "new world order". But these things take time.
ML
p.s. The name "SourceSafe" is merely used as an illustration.
http://milambda.blogspot.com/