Replacement of functions by procedures for SQL 7.0

Hello to everybody. I have problems with porting my sql function to elder version of SQL server.
7.0 doesnt have functions at all

Here is fragment of function I used before:

SELECT @.MessageCount = COUNT(RecordID)
FROM Msgs
WHERE dbo.GetGroup(Type) = dbo.GetGroup(@.Type)
AND RecordID <> @.RecordID
AND Receiver = @.Receiver
AND StartDate IS not NULL
AND dbo.CheckDateTime(
dbo.ExtractDate(@.StartDate),
dbo.ExtractDate(@.EndDate),
dbo.ExtractTime(@.StartDate),
dbo.ExtractTime(@.EndDate),
dbo.ExtractDate(StartDate),
dbo.ExtractDate(EndDate),
dbo.ExtractTime(StartDate),
dbo.ExtractTime(EndDate),
dbo.UsesTime(@.Type),
dbo.UsesTime([Type])) = 1

RETURN @.MessageCount

I replaced most of functions used in query with procedures. But how to implement query in better way if I cannot use functions?You should use scalar UDFs sparingly especially in SELECT statements. It hurts performance, limits plan choices and complicates performance troubleshooting. And using scalar UDFs for simple expressions is even more problematic. So remove the UDFs and replace them with the expression directly so it will work in any version of SQL Server and you can get the best performance also.

Replacement of functions by procedures for SQL 7.0

Hello to everybody. I have problems with porting my sql function to elder version of SQL server.
7.0 doesnt have functions at all

Here is fragment of function I used before:

SELECT @.MessageCount = COUNT(RecordID)
FROM Msgs
WHERE dbo.GetGroup(Type) = dbo.GetGroup(@.Type)
AND RecordID <> @.RecordID
AND Receiver = @.Receiver
AND StartDate IS not NULL
AND dbo.CheckDateTime(
dbo.ExtractDate(@.StartDate),
dbo.ExtractDate(@.EndDate),
dbo.ExtractTime(@.StartDate),
dbo.ExtractTime(@.EndDate),
dbo.ExtractDate(StartDate),
dbo.ExtractDate(EndDate),
dbo.ExtractTime(StartDate),
dbo.ExtractTime(EndDate),
dbo.UsesTime(@.Type),
dbo.UsesTime([Type])) = 1

RETURN @.MessageCount

I replaced most of functions used in query with procedures. But how to implement query in better way if I cannot use functions?You should use scalar UDFs sparingly especially in SELECT statements. It hurts performance, limits plan choices and complicates performance troubleshooting. And using scalar UDFs for simple expressions is even more problematic. So remove the UDFs and replace them with the expression directly so it will work in any version of SQL Server and you can get the best performance also.sql

Replacement for xp_cmdshell in SQL2k

ISSUE (in SQL Server 2000): Some Client applicationsâ' stored procedures are
using â'xp_cmdshellâ'.
xp_cmdshell is an extended stored procedure in Master database. This command
takes a string of dos commands and executes them in the DOS command shell.
Now the Client wants a replacement for this xp_cmdshell . i.e., I need some
other function or procedure or something which I can place instead of this
xp_cmdshell in the respective stored procedures using this xp_cmdshell.
Note: The Client doesnâ't want to use this xp_cmdshell at all.The client probably heard that having xp_cmdShell enabled adds to your
security risk, and wants a safe way to do the same things they have been
doing.
What have they been doing with xp_cmdshell? There may be ways to replace
that functionality, there may not.
You could create jobs that execute cmdexec steps, and have the stored
procedures activate the jobs.
Please provide more info about what they do and why they want to discontinue
using xp_cmdshell.
--
David Lundell
Principal Consultant and Trainer
www.MutuallyBeneficial.com
David@.MutuallyBeneficial.com
"aizaz" <aizaz@.discussions.microsoft.com> wrote in message
news:AC38DE7E-AD41-4414-AC0C-A8BC3C377DC7@.microsoft.com...
> ISSUE (in SQL Server 2000): Some Client applications' stored procedures
> are
> using "xp_cmdshell".
> xp_cmdshell is an extended stored procedure in Master database. This
> command
> takes a string of dos commands and executes them in the DOS command shell.
> Now the Client wants a replacement for this xp_cmdshell . i.e., I need
> some
> other function or procedure or something which I can place instead of this
> xp_cmdshell in the respective stored procedures using this xp_cmdshell.
> Note: The Client doesn't want to use this xp_cmdshell at all.
>|||The solution depends on what you are executing via xp_cmdshell. One
approach is to create a new extended stored procedure to encapsulate the
needed functionality.
Another method is to move the processing out of SQL Server and into
application code, either on the client or on a server. It is likely that
this is the better approach if your client is concerned about security.
Hope this helps.
Dan Guzman
SQL Server MVP
"aizaz" <aizaz@.discussions.microsoft.com> wrote in message
news:AC38DE7E-AD41-4414-AC0C-A8BC3C377DC7@.microsoft.com...
> ISSUE (in SQL Server 2000): Some Client applications' stored procedures
> are
> using "xp_cmdshell".
> xp_cmdshell is an extended stored procedure in Master database. This
> command
> takes a string of dos commands and executes them in the DOS command shell.
> Now the Client wants a replacement for this xp_cmdshell . i.e., I need
> some
> other function or procedure or something which I can place instead of this
> xp_cmdshell in the respective stored procedures using this xp_cmdshell.
> Note: The Client doesn't want to use this xp_cmdshell at all.
>|||Thank You for your response.
It is because of some security reasons the Client does not want any non-DBA
to use "xp_cmdshell" command.
This command takes a string as input and executes the same in the DOS
command shell. The string is nothing but a valid DOS command.
Example: Exec xp_cmdshell 'dir *.*'
Similarly as above my requirement has FTP, move, jview, copy, del, bcp etc.,
DOS commands as inputs to this extended stored procedure in the form of a
string.
I hope I explained it more clearly to you now.
-Aizaz
"David Lundell" wrote:
> The client probably heard that having xp_cmdShell enabled adds to your
> security risk, and wants a safe way to do the same things they have been
> doing.
> What have they been doing with xp_cmdshell? There may be ways to replace
> that functionality, there may not.
> You could create jobs that execute cmdexec steps, and have the stored
> procedures activate the jobs.
> Please provide more info about what they do and why they want to discontinue
> using xp_cmdshell.
> --
> David Lundell
> Principal Consultant and Trainer
> www.MutuallyBeneficial.com
> David@.MutuallyBeneficial.com
> "aizaz" <aizaz@.discussions.microsoft.com> wrote in message
> news:AC38DE7E-AD41-4414-AC0C-A8BC3C377DC7@.microsoft.com...
> > ISSUE (in SQL Server 2000): Some Client applications' stored procedures
> > are
> > using "xp_cmdshell".
> >
> > xp_cmdshell is an extended stored procedure in Master database. This
> > command
> > takes a string of dos commands and executes them in the DOS command shell.
> >
> > Now the Client wants a replacement for this xp_cmdshell . i.e., I need
> > some
> > other function or procedure or something which I can place instead of this
> > xp_cmdshell in the respective stored procedures using this xp_cmdshell.
> >
> > Note: The Client doesn't want to use this xp_cmdshell at all.
> >
>
>|||Thank You for your response.
A string of DOS commands is the input "xp_cmdshell".
Example:- Exec xp_cmdshell 'copy file1.txt file2.txt'
Which means we need some way in which we can take a string (which is a valid
DOS command) and execute it in DOS command shell (which is the functionality
of xp_cmdshell)
"Dan Guzman" wrote:
> The solution depends on what you are executing via xp_cmdshell. One
> approach is to create a new extended stored procedure to encapsulate the
> needed functionality.
> Another method is to move the processing out of SQL Server and into
> application code, either on the client or on a server. It is likely that
> this is the better approach if your client is concerned about security.
>
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "aizaz" <aizaz@.discussions.microsoft.com> wrote in message
> news:AC38DE7E-AD41-4414-AC0C-A8BC3C377DC7@.microsoft.com...
> > ISSUE (in SQL Server 2000): Some Client applications' stored procedures
> > are
> > using "xp_cmdshell".
> >
> > xp_cmdshell is an extended stored procedure in Master database. This
> > command
> > takes a string of dos commands and executes them in the DOS command shell.
> >
> > Now the Client wants a replacement for this xp_cmdshell . i.e., I need
> > some
> > other function or procedure or something which I can place instead of this
> > xp_cmdshell in the respective stored procedures using this xp_cmdshell.
> >
> > Note: The Client doesn't want to use this xp_cmdshell at all.
> >
>
>|||> Example:- Exec xp_cmdshell 'copy file1.txt file2.txt'
So why are you using xp_cmdshell for this task? Is there some reason you
cannot perform file manipulation like this directly from you application
code?
--
Hope this helps.
Dan Guzman
SQL Server MVP
"aizaz" <aizaz@.discussions.microsoft.com> wrote in message
news:B6A188BB-55FD-48C7-9A0F-6451EC953F7F@.microsoft.com...
> Thank You for your response.
> A string of DOS commands is the input "xp_cmdshell".
> Example:- Exec xp_cmdshell 'copy file1.txt file2.txt'
> Which means we need some way in which we can take a string (which is a
> valid
> DOS command) and execute it in DOS command shell (which is the
> functionality
> of xp_cmdshell)
> "Dan Guzman" wrote:
>> The solution depends on what you are executing via xp_cmdshell. One
>> approach is to create a new extended stored procedure to encapsulate the
>> needed functionality.
>> Another method is to move the processing out of SQL Server and into
>> application code, either on the client or on a server. It is likely that
>> this is the better approach if your client is concerned about security.
>>
>> --
>> Hope this helps.
>> Dan Guzman
>> SQL Server MVP
>> "aizaz" <aizaz@.discussions.microsoft.com> wrote in message
>> news:AC38DE7E-AD41-4414-AC0C-A8BC3C377DC7@.microsoft.com...
>> > ISSUE (in SQL Server 2000): Some Client applications' stored procedures
>> > are
>> > using "xp_cmdshell".
>> >
>> > xp_cmdshell is an extended stored procedure in Master database. This
>> > command
>> > takes a string of dos commands and executes them in the DOS command
>> > shell.
>> >
>> > Now the Client wants a replacement for this xp_cmdshell . i.e., I need
>> > some
>> > other function or procedure or something which I can place instead of
>> > this
>> > xp_cmdshell in the respective stored procedures using this xp_cmdshell.
>> >
>> > Note: The Client doesn't want to use this xp_cmdshell at all.
>> >
>>|||There is some processing done in a stored procedure and this extended stored
procedure is called after that. Once the xp completes its job, some more
processing done in the original stored procedure.
Also there are many stored procedures which internally call xp for different
tasks like bulk copy etc. Most of these stored procedures are scheduled SQL
tasks and are not called from any application. So replacing this
functionality in application code can be ruled out.
Thanks for your inputs/suggestions...
"Dan Guzman" wrote:
> > Example:- Exec xp_cmdshell 'copy file1.txt file2.txt'
> So why are you using xp_cmdshell for this task? Is there some reason you
> cannot perform file manipulation like this directly from you application
> code?
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "aizaz" <aizaz@.discussions.microsoft.com> wrote in message
> news:B6A188BB-55FD-48C7-9A0F-6451EC953F7F@.microsoft.com...
> > Thank You for your response.
> >
> > A string of DOS commands is the input "xp_cmdshell".
> >
> > Example:- Exec xp_cmdshell 'copy file1.txt file2.txt'
> >
> > Which means we need some way in which we can take a string (which is a
> > valid
> > DOS command) and execute it in DOS command shell (which is the
> > functionality
> > of xp_cmdshell)
> >
> > "Dan Guzman" wrote:
> >
> >> The solution depends on what you are executing via xp_cmdshell. One
> >> approach is to create a new extended stored procedure to encapsulate the
> >> needed functionality.
> >>
> >> Another method is to move the processing out of SQL Server and into
> >> application code, either on the client or on a server. It is likely that
> >> this is the better approach if your client is concerned about security.
> >>
> >>
> >> --
> >> Hope this helps.
> >>
> >> Dan Guzman
> >> SQL Server MVP
> >>
> >> "aizaz" <aizaz@.discussions.microsoft.com> wrote in message
> >> news:AC38DE7E-AD41-4414-AC0C-A8BC3C377DC7@.microsoft.com...
> >> > ISSUE (in SQL Server 2000): Some Client applications' stored procedures
> >> > are
> >> > using "xp_cmdshell".
> >> >
> >> > xp_cmdshell is an extended stored procedure in Master database. This
> >> > command
> >> > takes a string of dos commands and executes them in the DOS command
> >> > shell.
> >> >
> >> > Now the Client wants a replacement for this xp_cmdshell . i.e., I need
> >> > some
> >> > other function or procedure or something which I can place instead of
> >> > this
> >> > xp_cmdshell in the respective stored procedures using this xp_cmdshell.
> >> >
> >> > Note: The Client doesn't want to use this xp_cmdshell at all.
> >> >
> >>
> >>
> >>
>
>|||You might consider splitting the stored procedures that currently execute
xp_cmdshell into separate procs. This would allow you to replace
xp_cmdshell functionality with a CmdExec job step. For example:
1) Transact-SQL step: EXEC proc 1
2) CmdExec step: BCP
1) Transact-SQL step: EXEC proc 2
Your client might be more receptive to this method since the command runs
outside the SQL Server service process.
--
Hope this helps.
Dan Guzman
SQL Server MVP
"aizaz" <aizaz@.discussions.microsoft.com> wrote in message
news:0299E709-4A85-4158-B9A6-E62B1722765A@.microsoft.com...
>
> There is some processing done in a stored procedure and this extended
> stored
> procedure is called after that. Once the xp completes its job, some more
> processing done in the original stored procedure.
> Also there are many stored procedures which internally call xp for
> different
> tasks like bulk copy etc. Most of these stored procedures are scheduled
> SQL
> tasks and are not called from any application. So replacing this
> functionality in application code can be ruled out.
> Thanks for your inputs/suggestions...
> "Dan Guzman" wrote:
>> > Example:- Exec xp_cmdshell 'copy file1.txt file2.txt'
>> So why are you using xp_cmdshell for this task? Is there some reason you
>> cannot perform file manipulation like this directly from you application
>> code?
>> --
>> Hope this helps.
>> Dan Guzman
>> SQL Server MVP
>> "aizaz" <aizaz@.discussions.microsoft.com> wrote in message
>> news:B6A188BB-55FD-48C7-9A0F-6451EC953F7F@.microsoft.com...
>> > Thank You for your response.
>> >
>> > A string of DOS commands is the input "xp_cmdshell".
>> >
>> > Example:- Exec xp_cmdshell 'copy file1.txt file2.txt'
>> >
>> > Which means we need some way in which we can take a string (which is a
>> > valid
>> > DOS command) and execute it in DOS command shell (which is the
>> > functionality
>> > of xp_cmdshell)
>> >
>> > "Dan Guzman" wrote:
>> >
>> >> The solution depends on what you are executing via xp_cmdshell. One
>> >> approach is to create a new extended stored procedure to encapsulate
>> >> the
>> >> needed functionality.
>> >>
>> >> Another method is to move the processing out of SQL Server and into
>> >> application code, either on the client or on a server. It is likely
>> >> that
>> >> this is the better approach if your client is concerned about
>> >> security.
>> >>
>> >>
>> >> --
>> >> Hope this helps.
>> >>
>> >> Dan Guzman
>> >> SQL Server MVP
>> >>
>> >> "aizaz" <aizaz@.discussions.microsoft.com> wrote in message
>> >> news:AC38DE7E-AD41-4414-AC0C-A8BC3C377DC7@.microsoft.com...
>> >> > ISSUE (in SQL Server 2000): Some Client applications' stored
>> >> > procedures
>> >> > are
>> >> > using "xp_cmdshell".
>> >> >
>> >> > xp_cmdshell is an extended stored procedure in Master database. This
>> >> > command
>> >> > takes a string of dos commands and executes them in the DOS command
>> >> > shell.
>> >> >
>> >> > Now the Client wants a replacement for this xp_cmdshell . i.e., I
>> >> > need
>> >> > some
>> >> > other function or procedure or something which I can place instead
>> >> > of
>> >> > this
>> >> > xp_cmdshell in the respective stored procedures using this
>> >> > xp_cmdshell.
>> >> >
>> >> > Note: The Client doesn't want to use this xp_cmdshell at all.
>> >> >
>> >>
>> >>
>> >>
>>

Replacement for xp_cmdshell in SQL2k

ISSUE (in SQL Server 2000): Some Client applications’ stored procedures ar
e
using “xp_cmdshell”.
xp_cmdshell is an extended stored procedure in Master database. This command
takes a string of dos commands and executes them in the DOS command shell.
Now the Client wants a replacement for this xp_cmdshell . i.e., I need some
other function or procedure or something which I can place instead of this
xp_cmdshell in the respective stored procedures using this xp_cmdshell.
Note: The Client doesn’t want to use this xp_cmdshell at all.The client probably heard that having xp_cmdShell enabled adds to your
security risk, and wants a safe way to do the same things they have been
doing.
What have they been doing with xp_cmdshell? There may be ways to replace
that functionality, there may not.
You could create jobs that execute cmdexec steps, and have the stored
procedures activate the jobs.
Please provide more info about what they do and why they want to discontinue
using xp_cmdshell.
David Lundell
Principal Consultant and Trainer
www.MutuallyBeneficial.com
David@.MutuallyBeneficial.com
"aizaz" <aizaz@.discussions.microsoft.com> wrote in message
news:AC38DE7E-AD41-4414-AC0C-A8BC3C377DC7@.microsoft.com...
> ISSUE (in SQL Server 2000): Some Client applications' stored procedures
> are
> using "xp_cmdshell".
> xp_cmdshell is an extended stored procedure in Master database. This
> command
> takes a string of dos commands and executes them in the DOS command shell.
> Now the Client wants a replacement for this xp_cmdshell . i.e., I need
> some
> other function or procedure or something which I can place instead of this
> xp_cmdshell in the respective stored procedures using this xp_cmdshell.
> Note: The Client doesn't want to use this xp_cmdshell at all.
>|||The solution depends on what you are executing via xp_cmdshell. One
approach is to create a new extended stored procedure to encapsulate the
needed functionality.
Another method is to move the processing out of SQL Server and into
application code, either on the client or on a server. It is likely that
this is the better approach if your client is concerned about security.
Hope this helps.
Dan Guzman
SQL Server MVP
"aizaz" <aizaz@.discussions.microsoft.com> wrote in message
news:AC38DE7E-AD41-4414-AC0C-A8BC3C377DC7@.microsoft.com...
> ISSUE (in SQL Server 2000): Some Client applications' stored procedures
> are
> using "xp_cmdshell".
> xp_cmdshell is an extended stored procedure in Master database. This
> command
> takes a string of dos commands and executes them in the DOS command shell.
> Now the Client wants a replacement for this xp_cmdshell . i.e., I need
> some
> other function or procedure or something which I can place instead of this
> xp_cmdshell in the respective stored procedures using this xp_cmdshell.
> Note: The Client doesn't want to use this xp_cmdshell at all.
>|||Thank You for your response.
It is because of some security reasons the Client does not want any non-DBA
to use "xp_cmdshell" command.
This command takes a string as input and executes the same in the DOS
command shell. The string is nothing but a valid DOS command.
Example: Exec xp_cmdshell 'dir *.*'
Similarly as above my requirement has FTP, move, jview, copy, del, bcp etc.,
DOS commands as inputs to this extended stored procedure in the form of a
string.
I hope I explained it more clearly to you now.
-Aizaz
"David Lundell" wrote:

> The client probably heard that having xp_cmdShell enabled adds to your
> security risk, and wants a safe way to do the same things they have been
> doing.
> What have they been doing with xp_cmdshell? There may be ways to replace
> that functionality, there may not.
> You could create jobs that execute cmdexec steps, and have the stored
> procedures activate the jobs.
> Please provide more info about what they do and why they want to discontin
ue
> using xp_cmdshell.
> --
> David Lundell
> Principal Consultant and Trainer
> www.MutuallyBeneficial.com
> David@.MutuallyBeneficial.com
> "aizaz" <aizaz@.discussions.microsoft.com> wrote in message
> news:AC38DE7E-AD41-4414-AC0C-A8BC3C377DC7@.microsoft.com...
>
>|||Thank You for your response.
A string of DOS commands is the input "xp_cmdshell".
Example:- Exec xp_cmdshell 'copy file1.txt file2.txt'
Which means we need some way in which we can take a string (which is a valid
DOS command) and execute it in DOS command shell (which is the functionality
of xp_cmdshell)
"Dan Guzman" wrote:

> The solution depends on what you are executing via xp_cmdshell. One
> approach is to create a new extended stored procedure to encapsulate the
> needed functionality.
> Another method is to move the processing out of SQL Server and into
> application code, either on the client or on a server. It is likely that
> this is the better approach if your client is concerned about security.
>
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "aizaz" <aizaz@.discussions.microsoft.com> wrote in message
> news:AC38DE7E-AD41-4414-AC0C-A8BC3C377DC7@.microsoft.com...
>
>|||> Example:- Exec xp_cmdshell 'copy file1.txt file2.txt'
So why are you using xp_cmdshell for this task? Is there some reason you
cannot perform file manipulation like this directly from you application
code?
Hope this helps.
Dan Guzman
SQL Server MVP
"aizaz" <aizaz@.discussions.microsoft.com> wrote in message
news:B6A188BB-55FD-48C7-9A0F-6451EC953F7F@.microsoft.com...[vbcol=seagreen]
> Thank You for your response.
> A string of DOS commands is the input "xp_cmdshell".
> Example:- Exec xp_cmdshell 'copy file1.txt file2.txt'
> Which means we need some way in which we can take a string (which is a
> valid
> DOS command) and execute it in DOS command shell (which is the
> functionality
> of xp_cmdshell)
> "Dan Guzman" wrote:
>|||There is some processing done in a stored procedure and this extended stored
procedure is called after that. Once the xp completes its job, some more
processing done in the original stored procedure.
Also there are many stored procedures which internally call xp for different
tasks like bulk copy etc. Most of these stored procedures are scheduled SQL
tasks and are not called from any application. So replacing this
functionality in application code can be ruled out.
Thanks for your inputs/suggestions...
"Dan Guzman" wrote:

> So why are you using xp_cmdshell for this task? Is there some reason you
> cannot perform file manipulation like this directly from you application
> code?
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "aizaz" <aizaz@.discussions.microsoft.com> wrote in message
> news:B6A188BB-55FD-48C7-9A0F-6451EC953F7F@.microsoft.com...
>
>|||You might consider splitting the stored procedures that currently execute
xp_cmdshell into separate procs. This would allow you to replace
xp_cmdshell functionality with a CmdExec job step. For example:
1) Transact-SQL step: EXEC proc 1
2) CmdExec step: BCP
1) Transact-SQL step: EXEC proc 2
Your client might be more receptive to this method since the command runs
outside the SQL Server service process.
Hope this helps.
Dan Guzman
SQL Server MVP
"aizaz" <aizaz@.discussions.microsoft.com> wrote in message
news:0299E709-4A85-4158-B9A6-E62B1722765A@.microsoft.com...[vbcol=seagreen]
>
> There is some processing done in a stored procedure and this extended
> stored
> procedure is called after that. Once the xp completes its job, some more
> processing done in the original stored procedure.
> Also there are many stored procedures which internally call xp for
> different
> tasks like bulk copy etc. Most of these stored procedures are scheduled
> SQL
> tasks and are not called from any application. So replacing this
> functionality in application code can be ruled out.
> Thanks for your inputs/suggestions...
> "Dan Guzman" wrote:
>

Replace a string across multiple stored procedures

actually 2 questions.
a. Need to replace the string "server name" available on multiple stored
procedures p1,p2...p19
with ""?
can I do this with an update to system tables like syscomments?
b. Can I create a linked server to itself?> can I do this with an update to system tables like syscomments?
NO! Updates to system tables are not supported and are strongly
discouraged.
Script out the stored procedures as ALTER or DROP/CREATE (you can do this
using Enterprise Manager, Query Analyzer, or a host of other tools). Do the
replace operation in the output file, then apply that script to the server.
Have you heard of source control?|||Not to mention that changing the text in syscomments wouldn't actually
change the procedure, right?
----
Louis Davidson - http://spaces.msn.com/members/drsql/
SQL Server MVP
"Aaron Bertrand [SQL Server MVP]" <ten.xoc@.dnartreb.noraa> wrote in message
news:OTgoNCFlFHA.3568@.TK2MSFTNGP10.phx.gbl...
> NO! Updates to system tables are not supported and are strongly
> discouraged.
> Script out the stored procedures as ALTER or DROP/CREATE (you can do this
> using Enterprise Manager, Query Analyzer, or a host of other tools). Do
> the replace operation in the output file, then apply that script to the
> server.
> Have you heard of source control?
>|||> Not to mention that changing the text in syscomments wouldn't actually
> change the procedure, right?
That's correct, but I was nipping any other potential "what if I update
this, or what if I update that..." before they come up. :-)|||Yeah, no doubt :)
----
Louis Davidson - http://spaces.msn.com/members/drsql/
SQL Server MVP
"Aaron Bertrand [SQL Server MVP]" <ten.xoc@.dnartreb.noraa> wrote in message
news:eCverKFlFHA.2852@.TK2MSFTNGP15.phx.gbl...
> That's correct, but I was nipping any other potential "what if I update
> this, or what if I update that..." before they come up. :-)
>