Any pointers on how I can programmatically get exactly the identical stored procedure source from SQL Server 2005, as when I right-click on that stored procedure in SQL Server Management Studio and select modify?
I'm trying using SMO, but there are some textual differences. The procedure always has CREATE, not ALTER, and there are some differences in the header, such as missing GOs in the version I'm getting programmatically. I can fix these up, but perhaps there is a better way?
Again, I'm in SQL Server 2005, using SMSE. Using SMO via Visual Studio 8 2008.
Update: Gotten some answers that tell the basics of how to retrieve the stored procedure. What I'm looking for is retrieving the text identical (or nearly identical) to what the GUI generates.
Example: for sp_mysp, right-click in Management Studio, select modify. This generates:
USE [MY_DB] GO /****** Object: StoredProcedure [dbo].[sp_mysp] Script Date: 01/21/2009 17:43:18 ******/ SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO -- ============================================= -- Author: -- Create date: -- Description: -- ============================================= ALTER PROCEDURE [dbo].[sp_mysp]
I'd like to programmatically get the same thing (notice the GOs in the header, and the fact that it's an ALTER PROCEDURE. Ideally, I'd like to get this with minimal programmatic fixing up of the source retrieved.
I'd be happy to only get something that differed in the Script Date details . . .
You will have to hand code it, SQL Profiler reveals the following.
SMSE executes quite a long string of queries when it generates the statement.
The following query (or something along its lines) is used to extract the text:
It returns the pure CREATE which is then substituted with ALTER in code somewhere.
The SET ANSI NULL stuff and the GO statements and dates are all prepended to this.
Go with sp_helptext, its simpler ...
You said programmatically, right? I hope C# is ok. I know you said that you tried SMO and it didn't quite do what you wanted, so this probably won't be perfect for your request, but it will programmatically read out legit SQL statements that you could run to recreate the stored procedure. If it doesn't have the
GO
statements that you want, you can probably assume that each of the strings in theStringCollection
could have aGO
after it. You may not get that comment with the date and time in it, but in my similar sounding project (big-ass deployment tool that has to back up everything individually), this has done rather nicely. If you have a prior base that you wanted to work from, and you still have the original database to run this on, I'd consider tossing the initial effort and restandardizing on this output.