April 4, 2010 at 4:22 am
Ok this is driving me nuts :crazy:
The problem:
I need to extract out of the database all of the stored procedures that are about to be updated. I know what they are as I have a directory full of SQL files named for the procs.
So far I have been using the manual right click and export, but that is time consuming and error prone (no errors yet but you never know).
My solutions (so far):
I have so far tried to extract them using a batch file with a for loop that goes through the directory and collects all of the file names (the names will ALWAYS reflect the stored procedure in the file, no exceptions) then runs bcp.
Like so: bcp "Select routine_definition from %1.information_Schema.routines WHERE routine_name = '%%~nc'" queryout "%varbackup%\%%c" -c -T
That worked a treat until I looked closer at the files it output and saw that a couple of the bigger procs were only partially exported. Looking closer it was only exporting the first 4000 chars, this was due to the way information_Schema.routines works :blush:. I should have read that part a little closer.
So I tried:
bcp "SELECT Definition FROM sys.sql_modules WHERE object_id = OBJECT_ID('%%~nc')" queryout "%varbackup%\%%c" -c -T
Cool the SQL works in EM so it'll be fine, nope bcp produces an empty file :angry:
My reasoning behind the batch is as crude as the batch is, it's quick. Quick to edit if a change is required and quick to run during a frantic upgrade at some horrible time of the morning when no one should be awake.
So the crux of my post:
What SQL should I be running to make it spit out the procs?
Is this the best way to do it?
April 4, 2010 at 4:55 am
check out sp_helptext
---------------------------------------------------------------------
April 4, 2010 at 8:20 am
GarethPhilpott
So the crux of my post:
What SQL should I be running to make it spit out the procs?
Try this ... tested using SSMS -- with query output as text in new tab.
Select ROUTINE_SCHEMA, ROUTINE_NAME, ROUTINE_DEFINITION
From INFORMATION_SCHEMA.ROUTINES where ROUTINE_TYPE='PROCEDURE'
AND ROUTINE_DEFINITION LIKE '%update%'
April 9, 2010 at 7:55 pm
Thanks for the answers guys, unfortunately niether of them did the trick :(. I've decided just to add to a C# app that I've already written and use the SMO.
george sibbald
sp_helptext doesn't work with BCP properly, I found a couple of ways of doing it but they were far more complex than using SMO.
bitbucket-25253
Yup I had already tried that in SSMS (Thats how I constructed the query in the first place) and it pumped out the whole sp, BCP has a character limit for which there does not appear to be a switch to override.
April 10, 2010 at 4:29 am
why use bcp at all? Whats wrong with a SQLAgent job that outputs to a text file?
That sounds easier and quicker than a C# routine and SMO 🙂
---------------------------------------------------------------------
April 12, 2010 at 5:03 pm
I'm not sure if this would apply to your situation but, you might consider taking a different approach and setting up a database trigger which logs any procedure updates to a table:
CREATE trigger [dbtrg_ChangeLog]
on database
for create_procedure, alter_procedure, drop_procedure
as
set nocount on
declare @data xml
set @data = EVENTDATA()
INSERT INTO changelog(databasename, eventtype, objectname, objecttype, sqlcommand, loginname)
VALUES(
@data.value('(/EVENT_INSTANCE/DatabaseName)[1]', 'varchar(256)'),
@data.value('(/EVENT_INSTANCE/EventType)[1]', 'varchar(50)'),
@data.value('(/EVENT_INSTANCE/ObjectName)[1]', 'varchar(256)'),
@data.value('(/EVENT_INSTANCE/ObjectType)[1]', 'varchar(25)'),
@data.value('(/EVENT_INSTANCE/TSQLCommand)[1]', 'varchar(max)'),
@data.value('(/EVENT_INSTANCE/LoginName)[1]', 'varchar(256)')
)
April 12, 2010 at 5:47 pm
george sibbald
Yeah an agent job could have worked, oh well it only took me a couple of hours to write the SMO code.
Having said that though the SMO solution is less than 40 lines long and that includes error handling, comments and a lot of whitespace 🙂
Carlo Mitchell
Yeah I could do that, but BCP was the peice that was failing. The SQL I was running was returning the procedure correctly so there was no need to replicate something that SQL Server already does. I'm also not a fan of storing them that way as all it takes is the trigger to fail once at a critical time and the table is one step behind what the database has as the latest procedure or worse it's mangled.
March 4, 2014 at 6:16 pm
Hmm... this is working for me...
c:>bcp "select text from sys.syscomments where id=OBJECT_ID('procname')" QUERYOUT "procname.sql" -S server -d database -T
Even better, if I create a text file of proc (or view, function or trigger) names:
c:>for /f %f in (proclist.txt) do @bcp "select text from sys.syscomments where id=OBJECT_ID('%f')" QUERYOUT "%f.sql" -S server -d database -T
If using a version of bcp that doesn't support -d database, then modify the query to:
select text from database.sys.comments
Wish there was a bit easier way to extract table DDL (yes, there's SMO)...
March 4, 2014 at 6:23 pm
Ooops... my bcp commands should include the -c option...
C:>for /f %f in (proclist.txt) do @bcp "select text
from sys.syscomments where id=OBJECT_ID('%f')" queryout "%f.txt" -S server
-d database -T -c
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply