The title pretty much says it all.
How can I view the original SQL that created a stored procedure in SQL Server 2008?
Is this possible? I've been searching online for some leads, but I'm either missing correct vernacular or I'm just looking for something that can be found by some other means.
My basic problem is that I've got a SQL Server 2008 db here with a couple hundred stored procedures and I want to see what they are doing. I need to copy one and modify it slightly and then use it.
Open up management studio and expand the database you are after. Inside of there is a programmability folder, expand that and you will see the stored procedures. Right click on one of them and select modify.
From a query window on the db you can execute sp_helptext YOURPROCEDURENAME It's a shorthand for what Martin described.
To get the definition
select object_definition(object_id('sp_help'))
Or in management studio right click the procedure and choose a scripting option.
As long as it was not encrypted sp_helptext is the stored procured you want to show the text of any stored procedure
Of course if you were storing your sps in your source control as you should be doing, you would go there and look at it and even be able to see previous versions.
For any of the answers given so far, if there was any set up done - to create a #temp table that the proc depends on, for example - that won't exist in the results because SS stores the functional code for the proc definition, not all of the SQL used in the creation. Some things you might have to infer.
Related
I'm not sure if a stored procedure is the correct path here so first, I'll explain what I need to accomplish.
I need to query one table with a variable as such:
SELECT *
FROM db.partList
WHERE column1 = 'order_no';
Then, I need to query another table as such:
SELECT [serial_no]
FROM db.resultsList;
Finally I need to iterate through the results of the above, and return the first [serial_no] from db.partList that is not in the list produced.
The original programmer was doing this in a way that was blowing up the customer's network unnecessarily. There shouldn't be any reason this can't be done locally. Now I'm here to clean it up.
Thanks in advance.
So my questions are, would this be correct use of a stored procedure? If so, could someone perhaps give me some sample code to start working with? I don't often have to dive that deep into SQL Server.
This is SQL Server 2012.
I've got some example code of how I would do it in other languages if needed. I'm just not familiar enough with stored procedures to do this quickly.
I have a project that requires me to do development in SQL Server 2005, but do deployments to a SQL Server 2000 box.
For 99% of the SQL code, I have no problems, everything appears to be backwards compatible.
Now I am just about to start adding all the Stored Procedures (SPs) to source control, and I like the idea of doing a drop-add each time the query is executed. I.E. If the SP already exists, first drop it. Then create/re-create the SP.
How do I do this in a single script, in a manner that is compatible with both SQL 2000 and SQL 2005, so that my scripts will just work during Development (2000) AND Production (2005)? I believe the syntax is slightly different, and the SP metadata is stored in different system tables.
Please assist with a working SQL script.
This works for both SQL 2000 and SQL 2005. I have tested it right now.
USE databasename
GO
IF object_id('schema.StoredProcedureName') IS NOT NULL
DROP PROCEDURE schema.StoredProcedureName
GO
CREATE PROCEDURE schema.StoredProcedureName
.. your code
Don't use system tables: use OBJECT_ID
I would also deploy using ALTER but maintain source control using CREATE. That is, I only ever use differential deployment scripts (with ALTER) but compare to my source control folder after release (which as CREATE)
I have both code history and simpler deployments: there is no need to drop/create all procs. What if you forget a permission for example?
I use Red Gate/SVN BTW
I think
IF OBJECT_ID('your_sp_name') IS NOT NULL
will tell you if it is there, although I can't test on 2000 at the mo...
FWIW
select * from sysobjects where type = 'p'
still works in SQL 2008, so am guessing that this is still acceptable as the lowest common denominator. DMV's weren't available in 2000.
You best option is staill the compatibility views, sysobects, syscolumns, etc
Check out the following link
http://msdn.microsoft.com/en-us/library/ms187376.aspx
Many of the system tables from earlier
releases of SQL Server are now
implemented as a set of views. These
views are known as compatibility
views, and they are meant for backward
compatibility only. The compatibility
views expose the same metadata that
was available in SQL Server 2000.
It seems to me that you recreate all STORED PROCEDUREs with respect of sys.sp_refreshsqlmodule like if is described in my old answer I'm looking for a reliable way to verify T-SQL stored procedures. Anybody got one?. The code of STORED PROCEDUREs will be one more time verified inclusive off dependencies.
Using the INFORMATION_SCHEMA.ROUTINES view should work in SQL Server 2000, 2005, and 2008. The only downside is that the view is no longer a viable means of determining the object's schema.
But if that is not a concern, try a script like this:
USE YourDB
GO
IF EXISTS (
SELECT *
FROM INFORMATION_SCHEMA.ROUTINES
WHERE ROUTINE_NAME = 'usp_test'
) DROP PROCEDURE usp_test
GO
CREATE PROCEDURE usp_test AS
SELECT 1 AS val
GO
EXEC usp_test
GO
In most cases, I'd try to run SQL2000 TSQL on the 2005 box, as I'd expect it to be largely backward-compatible. That said, you ought to finish upgrading your production box so you can use newer TSQL.
In cases where you can't find compatibility between the versions, you could first detect the version.
To determine which version of SQL Server 2000/2005 is running, connect to SQL Server 2000/2005 by using Query Analyzer, and then run the following code:
SELECT
SERVERPROPERTY('productversion'),
SERVERPROPERTY ('productlevel'),
SERVERPROPERTY ('edition')
The results are:
The product version (for example, 8.00.534).
The product level (for example, “RTM” or “SP2″).
The edition (for example, “Standard Edition”).
For example, the result looks similar to:
8.00.534 RTM Standard Edition
Source: http://blog.sqlauthority.com/2007/03/07/sql-server-script-to-determine-which-version-of-sql-server-2000-2005-is-running/
Once you determine the version, you can execute the proper level of code.
I need to change the database name in SQL SERVER 2008 and use it in another project. However it consist hundreds of stored procedures and the name of the database should be changed in the stored procedures as well. Is there any way to do this?
If you right mouse click a Database and choose Tasks->Generate Scripts. Go through the Wizard and it will create a SQL script for you. Make sure that you select all of the necessary options e.g. Create Database, Stored Procedures etc. Once finished, you'll have a big script. Find and replace the database name.
I would suggest that you export all your stored procedures as sql-files and then take a nice texteditor (like Notepad++) and make a file-search&replace-action to change all the names referenced inside the sql-files.
There is no other way around as far as I can say :-(
I'd make next thing: I'd generate all scripts for database by Management Studio(Right Click on DB -> Tasks -> Generate scripts), after that I'd replace name of database (Ctrl + H).
Right click on the database, Tasks -> Generate scripts, select stored procedure, and open the scripts in sql editor.
Search and replace the database or string names.
replace Create procedure with Alter procedure.
Compile and done.
There is no way of doing this automatically. You would have to manually change every stored procedure.
Do you really need to change the name?
Wouldn't it be better to keep everything the same and use a different server or server instance? Are you going to have to maintain database changes through these two datbases with the different names?
Is there command inside a Query Window that will open a stored procedure in another Query Window?
i.e.
MODIFY dbo.pCreateGarnishmentForEmployee
I am using SQL Server management Studio 2005 and Red Gate's SQL Prompt.
Currently I have to do the follwowing multiple steps:
Open Object Explorer
Navigate Programmability | Stored Procedure
Right Click the Stored Procedure name
Select Modify
A Query Window will open up with the ALTER PROCEDURE.
As I mentioned above, what I would like to do is from a Query Window type
in something to the effect of
MODIFY dbo.pCreateGarnishmentForEmployee
You are trying to mix two technologies here.
SQL and SQLSyntax
The SQL Management Tool
It is probably not possible to use TSQL to manipulate the Management Studio, which is what you appear to want. I suspect cut and paste is your only option.
I think that the only way that I'm aware of that produces an outcome similar to what you're asking for is running sp_helptext against your stored procedure name
sp_helptext 'dbo.pCreateGarnishmentForEmployee'
which will output the text as a resultset. Then click on the column header and copy/paste the resultset into the query window. You'll also need to change the
CREATE PROCEDURE ...
to
ALTER PROCEDURE ...
This method does not always produce the nicely formatted layout of your stored procedure however, so bear this in mind.
There is a way to do this from the command line (i.e., from outside of SSMS).
It requires that you save your stored procedure text (as in, click "save", not execute). Here's an example:
Ssms "C:\...\SQL Server Management Studio Projects\mySolution\myProject\myScript.sql"
See the article on MSDN for more detailed info: http://msdn.microsoft.com/en-us/library/ms162825.aspx
I know that you can do this in SQL Server 2005, but I'm at a loss for 2000.
Not to my knowledge.
To get around this, I manage my stored procedures in a Visual Studio database project. Every stored procedure is in its own file and has a drop command at the top of the file. When I update the stored through Visual Studio, the database's created date is updated in the database because of the drop/create statement. I am able to use the created date in SQL Server 2000 as the last modified date in this manner.
From all the research I've done on this in the past, I unfortunately have to say no. SQL Server 2000 simply does not store this information, and I've never seen any solution for retrieving it.
There are a few alternative methods, but they all involve user intervention. Besides keeping stored procedure scripts in a source control system, I think the next best approach is to use comments inside the stored procedure. Not ideal, but it's better than nothing if you want to track what gets updated.
SELECT crdate
FROM sysobjects
WHERE name = 'proc name here'
AND type = 'P'
It looks like you could use : SELECT * FROM INFORMATION_SCHEMA.ROUTINES
Found here : Date object last modified