The Curse of Dynamic SQL

[NickName]

Task:
Create 100 or so stored procedure scripts similar to the convention of
Generating Script from EM automatically. I thought of essentially two
things of a) using sp_helptext to get the content of a sp; and b) using
bcp to write such content to a (dynamic) file. What bugs me is really
the curse of dynamic sql.

process inside a cursor:
------------------------
exec master..xp_cmdshell 'bcp "exec sp_helptext '+@spName+'" queryout
'+@spName+'.txt -c -SmyServerName -Usa -PmyPwd'

Error = [Microsoft][ODBC SQL Server Driver]Function sequence error
TIA

[joshsackett]

This is going to help you MUCH more than doing it that way.

http://www.sqlservercentral.com/colu...tionscript.asp

[NickName]

While it is good to know such a utility tool it does not serve the
purpose of the task in question. I mentioned about each seperate sp
because some of them (not all) might be shared among several similar
databases.

[joshsackett]

This is about as close as I can get you:
declare @spName varchar(256)
declare @sql varchar(1024)

declare my_cur cursor for
select name from sysobjects where type = 'P'
open my_cur
fetch next from my_cur into @spName
while @@fetch_status = 0
begin
set @sql = 'osql -SServerName -UUsername -PPassword -n -h
-dDatabaseName -Q "set nocount on declare @tbl_temp table(textvalue
varchar(512)) insert into @tbl_temp exec sp_helptext '+@spName+' select
rtrim(textvalue) from @tbl_temp" -o C:\'+@spName+'.txt'
print @sql
exec master..xp_cmdshell @sql
fetch next from my_cur into @spName
end
close my_cur
deallocate my_cur

[Simon Hayes]

"NickName" <da****@rock.com> wrote in message
news:11*********************@o13g2000cwo.googlegro ups.com...

Task:
Create 100 or so stored procedure scripts similar to the convention of
Generating Script from EM automatically. I thought of essentially two
things of a) using sp_helptext to get the content of a sp; and b) using
bcp to write such content to a (dynamic) file. What bugs me is really
the curse of dynamic sql.

process inside a cursor:
------------------------
exec master..xp_cmdshell 'bcp "exec sp_helptext '+@spName+'" queryout
'+@spName+'.txt -c -SmyServerName -Usa -PmyPwd'

Error = [Microsoft][ODBC SQL Server Driver]Function sequence error
TIA

The most reliable and flexible way to generate scripts in MSSQL is using
SQLDMO, which is a COM interface for managing MSSQL. Although you could read
syscomments (and in fact SQLDMO does this behind the scenes), SQLDMO allows
you to customize the scripts to included permissions, owner name, headers
etc. You can use SQLDMO from any language which can work with COM objects -
Perl, VBScript, C# etc. See Books Online for more details.

It's also worth noting that using syscomments or sp_helptext will not give
you all the information you need. For example, SET QUOTED_IDENTIFIER and SET
ANSI_NULLS are fixed when you create a procedure, but whether these settings
are on or off is not included in syscomments.

Simon

[NickName]

OK, you're using a slightly different approach, I'll check it out
later. Thanks.

[NickName]

Ahe, I did not write but in my thought process I included that as well,
I call them "header" (which include object verification and drop
routine as well) and "end header", intended to prefix before bcp for
"header" and append "end header" at the end. Thanks. btw, are you
able to 'cure' the curse in question with my approach?

[Simon Hayes]

"NickName" <da****@rock.com> wrote in message
news:11*********************@f14g2000cwb.googlegro ups.com...

Ahe, I did not write but in my thought process I included that as well,
I call them "header" (which include object verification and drop
routine as well) and "end header", intended to prefix before bcp for
"header" and append "end header" at the end. Thanks. btw, are you
able to 'cure' the curse in question with my approach?

To be honest I wouldn't even try. Any TSQL solution for this kind of problem
tends to end up being complicated and tough to maintain. On the other hand,
this VBScript snippet will script every stored proc in your database to the
current folder (ie where the script is), and is a lot clearer and easier to
customize (in my opinion):

Option Explicit

Dim srv, proc, filename

Set srv = WScript.CreateObject("SQLDMO.SQLServer2")
srv.Name = "MyServer"
srv.LoginSecure = True
srv.Connect()

For Each proc In srv.Databases("MyDatabase").StoredProcedures
If Not proc.SystemObject Then
filename = proc.Name & ".sql"
proc.Script 4, filename
End If
Next

In this case, 4 is a SQLDMO constant to script with the default options -
see "Script Method" under SQLDMO in Books Online for the full list.
Unfortunately, VBScript can't import COM constants automatically, so you
have to use constant values instead of the more descriptive names.

Simon

[NickName]

Interesting alternative. However, I'll try to stay with T-SQL, not
that I'm not open to new technique/thing but, to me, the projected
benefits are not that substantial. As for this particular case, it's
one time solution though the process could be re-used later if proved
to be working as expected.

[Erland Sommarskog]

NickName (da****@rock.com) writes:

Create 100 or so stored procedure scripts similar to the convention of
Generating Script from EM automatically. I thought of essentially two
things of a) using sp_helptext to get the content of a sp; and b) using
bcp to write such content to a (dynamic) file. What bugs me is really
the curse of dynamic sql.

process inside a cursor:
------------------------
exec master..xp_cmdshell 'bcp "exec sp_helptext '+@spName+'" queryout
'+@spName+'.txt -c -SmyServerName -Usa -PmyPwd'

Error = [Microsoft][ODBC SQL Server Driver]Function sequence error

The above is not legal SQL; you cannot have expressions as parameters
to stored procedure.

But you are really in a dead end. You could get the thing to work, but
the files you get could still be mashed. The code is stored in
syscomments as a sequence of varchar(8000), and a token may be split
over two rows. sp_helptext makes some attempts to repair this, but if
there are comments in the beginning, it's a complete failure.

Using SQL-DMO is probably your most efficient way.

--
Erland Sommarskog, SQL Server MVP, es****@sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinf...2000/books.asp

[NickName]

Did you have a chance to run the script yourself? I just tried with a
slight twist, that is, I first compare all the procs in two identical
dbs and fetch the mismatched ones into a temp tbl, then loop them
through a cursor, within the cursor I used your technique, got err
"{the long command string} is not a valid identifier", btw, BOL has no
indication as to which OSQL param is mandatory and which ones are
optional. Further thought?

[NickName]

I appreciate your insight. "But you are really in a dead end.", to me,
that is really an indication of the lack of "superPower" of a complex
tool, be it MS SQL Server 2000 or Oracle 10 for that matter.

[Erland Sommarskog]

NickName (da****@rock.com) writes:

I appreciate your insight. "But you are really in a dead end.", to me,
that is really an indication of the lack of "superPower" of a complex
tool, be it MS SQL Server 2000 or Oracle 10 for that matter.

It's more a matter of using the right tool for a job. Do you always
use hammers to push your screws?

That said, in SQL 2005 it would be a little easier. At least the risk
for broken lines is not there.
--
Erland Sommarskog, SQL Server MVP, es****@sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinf...2000/books.asp

[Erland Sommarskog]

NickName (da****@rock.com) writes:

Did you have a chance to run the script yourself? I just tried with a
slight twist, that is, I first compare all the procs in two identical
dbs and fetch the mismatched ones into a temp tbl, then loop them
through a cursor, within the cursor I used your technique, got err
"{the long command string} is not a valid identifier", btw,
Since you did not include the twist, and also insisted on not including
the complete error message, you cannot count for much help. But apparently
you used " where you should have used '. By default " delimites identifiers,
not string literals. (But in OSQL, it's actually different to confuse.)

However, I do spot an error in Josh's suggestion: he inserts into a
table variable. That does not fly with INSERT-EXEC. Must use temp table.
BOL has no indication as to which OSQL param is mandatory and which ones
are optional.

It has. If you look at the syntax grapgh you will see that no option
is mandatory, but that there are four options of which you must pick
one.
--
Erland Sommarskog, SQL Server MVP, es****@sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinf...2000/books.asp

[NickName]

"It's more a matter of using the right tool for a job. Do you always
use hammers to push your screws? "
I respectively disagree on the above, howver, appreciate the info
below.
"That said, in SQL 2005 it would be a little easier. At least the risk
for broken lines is not there. " And you know what, I may be able to
find a solution other than SQL-DMO on a good day (I've proven it) but
not today.

[NickName]

Update, have been working on the problem on and off, finally resolved
it in a way I desired. I came up with the idea of redireting proc
content to a DOS file, sort of like
set @sql = 'echo '+@baboon+' >> C:\procs\'+@spName+'.sql'
exec master..xp_cmdshell @sql
on June 20th.
But stumbled by carrige return, which I overlooked, a co-worker has
experience in this, who pointed it out. I understand your intention
and appreciate it.

DL