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_cmds hell 'bcp "exec sp_helptext '+@spName+'" queryout
'+@spName+'.txt -c -SmyServerName -Usa -PmyPwd'

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


TIA

[joshsackett]

Re: The Curse of Dynamic SQL

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

http://www.sqlservercentral.com/columnists/jreade/howtoscheduleasqlserverdatabasecreationscript.asp

[NickName]

Re: The Curse of Dynamic SQL

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]

Re: The Curse of Dynamic SQL

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_cmds hell @sql
fetch next from my_cur into @spName
end
close my_cur
deallocate my_cur

[Simon Hayes]

Re: The Curse of Dynamic SQL


"NickName" <dadada@rock.co m> wrote in message
news:1118851451 .087476.31390@o 13g2000cwo.goog legroups.com...[color=blue]
> 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_cmds hell 'bcp "exec sp_helptext '+@spName+'" queryout
> '+@spName+'.txt -c -SmyServerName -Usa -PmyPwd'
>
> Error = [Microsoft][ODBC SQL Server Driver]Function sequence error
>
>
> TIA
>[/color]

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_IDENTIFI ER 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]

Re: The Curse of Dynamic SQL

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

[NickName]

Re: The Curse of Dynamic SQL

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]

Re: The Curse of Dynamic SQL


"NickName" <dadada@rock.co m> wrote in message
news:1118863083 .947212.68850@f 14g2000cwb.goog legroups.com...[color=blue]
> 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?
>[/color]

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.CreateO bject("SQLDMO.S QLServer2")
srv.Name = "MyServer"
srv.LoginSecure = True
srv.Connect()

For Each proc In srv.Databases(" MyDatabase").St oredProcedures
If Not proc.SystemObje ct 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]

Re: The Curse of Dynamic SQL

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]

Re: The Curse of Dynamic SQL

NickName (dadada@rock.co m) writes:[color=blue]
> 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_cmds hell 'bcp "exec sp_helptext '+@spName+'" queryout
> '+@spName+'.txt -c -SmyServerName -Usa -PmyPwd'
>
> Error = [Microsoft][ODBC SQL Server Driver]Function sequence error[/color]

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, esquel@sommarsk og.se

Books Online for SQL Server SP3 at

http://www.microsoft.com/sql/techinfo/productdoc/2000/books.asp

[NickName]

Re: The Curse of Dynamic SQL

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]

Re: The Curse of Dynamic SQL

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]

Re: The Curse of Dynamic SQL

NickName (dadada@rock.co m) writes:[color=blue]
> 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.[/color]

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, esquel@sommarsk og.se

Books Online for SQL Server SP3 at

http://www.microsoft.com/sql/techinfo/productdoc/2000/books.asp

[Erland Sommarskog]

Re: The Curse of Dynamic SQL

NickName (dadada@rock.co m) writes:[color=blue]
> 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,[/color]

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.
[color=blue]
> BOL has no indication as to which OSQL param is mandatory and which ones
> are optional.[/color]

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, esquel@sommarsk og.se

Books Online for SQL Server SP3 at

http://www.microsoft.com/sql/techinfo/productdoc/2000/books.asp

[NickName]

Re: The Curse of Dynamic SQL

"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.