I created many numbered stored procedures in SQL Server 2008.
Their names are e.g.: dbo.ProcName, dbo.ProcName;2, dbo.ProcName;3,...
When I use rightclick on procedure name in procedures list in Management Studio 2008 and then click to Modify I can see and edit all stored procedure as I wrote above.
But in Management Studio 2012, after same action, I can see only the first procedure.
How to see and edit all stored procedures with the same name and suffix with semicolon?
Sounds like you are talking about numbered stored procedures.
I can reproduce the same behaviour. After running the following
CREATE PROCEDURE [dbo].[foo];1 #x int AS
PRINT 'x is ' + CONVERT(varchar(8), #x)
GO
CREATE PROCEDURE [dbo].[foo];2 #x char AS
PRINT 'x is ' + #x
GO
Selecting "Foo" in object explorer then "Modify" shows both versions in SSMS 2008 but only the first one in SSMS 2012.
These have been deprecated since 2005 so I wouldn't be surprised if it is a deliberate decision not to support them in the tools any more. Looks like Drop and Create still lists both versions though.
Another workaround:
EXEC sp_helptext 'dbo.ProcName';
You'll have to inject the GOs yourself, though.
You can also get the metadata this way:
SELECT definition
FROM sys.sql_modules
WHERE [object_id] = OBJECT_ID('dbo.ProcName')
UNION ALL
SELECT definition
FROM sys.numbered_procedures
WHERE [object_id] = OBJECT_ID('dbo.ProcName');
And this way:
SELECT [text] FROM syscomments
WHERE id = OBJECT_ID('dbo.ProcName');
And you can go through the Generate Scripts wizard:
right-click your database and choose Tasks > Generate Scripts
On the 'Choose Objects' screen, select 'Select specific database objects, check 'Stored Procedures', and expand to select the root name of the numbered stored procedure(s) you want to script.
On the 'Set Scripting Options' screen, choose 'Save to new query window.'
Click Next > Next > Finish.
I also filed a bug on this:
http://connect.microsoft.com/SQLServer/feedback/details/764197/ssms-2012-inconsistently-handles-numbered-procedures
Related
In SQL Server Management Studio (SSMS), you can execute a stored procedure using the GUI for assistance. This can done by right-clicking on the stored procedure in the Object Explorer and selecting either "Execute Stored Procedure" or "Script Stored Procedure as > CREATE to > New Query Editor Window".
Both of these result in a pre-built SQL query to execute the SP, and both of them include optional parameters from the SP. Is there a way to make it so the optional parameters are "hidden"?
I have some user support folks who use SSMS to run certain SPs, and I don't want them providing values for certain optional parameters. I want to be able to provide them myself, if needed, when I run the SP, but not the user support people.
I've tagged SQL Server 2014 and 2008 R2 in case there's some option I can set in the SP itself.
You could wrap your stored procedure with another:
CREATE PROCEDURE dbo.my_orig_proc
#id INT
,#some_param_default INT = 10
AS
BEGIN
...
END
Wrapper:
CREATE PROCEDURE dbo.my_wrapper_proc
#id INT
AS
BEGIN
EXEC dbo.my_orig_proc #id;
END
I would also restrict access to orignal procedures if necessary.
Another way is to add check and don't allow specific user to override value:
CREATE PROCEDRUE dbo.my_orig_proc
#id INT,
,#some_param_default INT = 10
AS
BEGIN
IF USER_NAME() = 'user_name' AND #some_param_default <> 10
RAISERROR('You cannot change #some_param_default value' ,16,1);
END
Drawback: You need to change parameter value in two places and if user has impersonate privilige he still can execute it.
I use SQL Server 2012 and SQL Server 2008 R2.
I create a script from all object (tables / trigger / stored procedure / function ...) in my database.
I generated this script from SQL Server Management Studio. I can recreate my database with this scrips on the other server. But I miss all diagrams of my database after run my script for create another database.
Therefore, I need create backup script from all diagrams that exist in my database.
I need execute this script on the destination database for recreating all my diagrams.
I found this Link. but i need some thinks that create all script (Insert Command) automatically.
I have found a reasonable solution. The problem is that Management Studio cannot display more that 65535 characters for Non-XML data, and cannot be set to display more than 65535.
See code for documentation :)
Backup script:
-- 1. Read from DB, using XML to workaround the 65535 character limit
declare #definition varbinary(max)
select #definition = definition from dbo.sysdiagrams where name = 'ReportingDBDiagram'
select
'0x' + cast('' as xml).value('xs:hexBinary(sql:variable("#definition") )', 'varchar(max)')
for xml path('')
-- 2. Open the result XML in Management Studio
-- 3. Copy the result
-- 4. Paste this in backup script for #definition variable
Restore script:
declare #definition varbinary(max)
set #definition = 0xD0CF -- Paste 0x0 value from Backup script
-- Create diagram using 'official' Stored Procedure
exec dbo.sp_creatediagram
#diagramname = 'ReportingDBDiagramCopy',
#owner_id = null,
#version = 1,
#definition = #definition
Scripting your database does not include diagrams as they are not server objects in the same way as a table or stored procedure; they exist as data in the sysdiagrams table.
A similar question on SO asked How do you migrate SQL Server Database Diagrams to another Database?
The accepted answer is to copy the contents of the sysdiagrams table to the new database, so you could include the table contents in your script. The answer with the most up-votes has a link to a way of scripting diagrams.
I've tried backing up and then restoring a database to the same server, deleting the diagram I had created (I only had one) and then running the following query:
INSERT INTO database2.dbo.sysdiagrams
(
NAME
,principal_id
,version
,DEFINITION
)
SELECT NAME
,principal_id
,version
,DEFINITION
FROM database1.dbo.sysdiagrams
The diagram was successfully restored, however I did do this on a restored backup, I should really test it with a new database generated from a script.
UPDATE:
I scripted a database and then created a new database from it. When trying to rebuild the diagrams using an INSERT statement I got the error
So although it seems possible it's not trivial to create diagrams in a new database created from a script. Go with the answer given regarding scripting diagrams and modify it for your own needs.
Perhaps you can investigate further and post your own answer :)
Here's a quick & dirty method I use. Since the query window won't display the full varbinary(max) value of the definition field, but the XML editor will, I output the rows to XML as follows:
Run the following query on the server/database that contains the diagrams:
SELECT 'INSERT sysdiagrams(name,principal_id,diagram_id,version,definition) VALUES('''+name+''','
+CONVERT(varchar(2),principal_id)+','+CONVERT(varchar(2),diagram_id)+','+CONVERT(varchar(2),version)+','
+'0x' + CAST('' as xml).value('xs:hexBinary(sql:column("definition"))','varchar(max)') +')'
FROM RCSQL_ClaimStatus.dbo.sysdiagrams
FOR XML PATH
Click on the generated link to open the XML result, and ctrl-a & ctrl-c to copy all rows generated.
Paste that output back into your query window. I usually paste it between a pair of IDENTITY_INSERT's like this:
--TRUNCATE TABLE sysdiagrams
SET IDENTITY_INSERT sysdiagrams ON;
<row>INSERT sysdiagrams(name,principal_id,diagram_id,version,definition) VALUES('ERD1',1,1,1,0xD0CF11E0A1B11AE100000...)</row>
<row>INSERT sysdiagrams(name,principal_id,diagram_id,version,definition) VALUES('ERD2',1,2,1,0xD0CF11E0A1B11AE100000...)</row>
<row>INSERT sysdiagrams(name,principal_id,diagram_id,version,definition) VALUES('ERD3',1,3,1,0xD0CF11E0A1B11AE100000...)</row>
SET IDENTITY_INSERT sysdiagrams OFF;
Remove the row & /row XML tags from your inserts, and run them on the target server. You can truncate the sysdiagrams table if you're replacing all values with new values.
Whenever I attempt to "modify" or use the "script to" function with a stored procedure within SQL Server Management Studio, every single quote in the SP is replaced with a double quote. Whenever any of my colleagues uses modify or script to, they receive the output in single quotes. The double quotes break the query. It appears to be a setting within SSMS, but I cannot find any such setting.
Any advice would be appreciated.
I believe you are getting dynamic SQL from the scripting options because you have this option selected:
Tools > Options > SQL Server Object Explorer > Scripting > Check for object existence
When this setting is enabled, the script is generated like this:
IF NOT EXISTS (SELECT * FROM sys.objects WHERE object_id = ...)
BEGIN
EXEC dbo.sp_executesql #statement = N'ALTER PROCEDURE...'
END
Disable this option, and it should be correct when you use right-click > Modify or right-click > Script stored procedure as > ALTER to >.
The stored procedure scripts that SQL Server Management Studio 2005 generates for me are like:
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER OFF
GO
IF NOT EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].[APY_SP_ACH_Transmit_Finish]') AND type in (N'P', N'PC'))
BEGIN
EXEC dbo.sp_executesql #statement = N'
...
print ''arg!, all the quotes are escaped''
...
'
END
so all the quotes are escaped. is there a way or option to turn this off?
in SQL Server Management Studio 2005. I do the following:
1) In Object Explorer, locate the procedure I want to script out
2) right click, and select script stored procedure as "Create To"
3) selecting file or clipboard has the same effect.
This seems to happen when the scripting option "Include If NOT EXISTS" clause is on.
Do you need this on? If not you can turn it off via the
Tools -> Options -> Scripting
From this Connect item it doesn't look configurable without that.
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 . . .
EXEC sp_helptext 'your procedure name';
This avoids the problem with INFORMATION_SCHEMA approach wherein the stored procedure gets cut off if it is too long.
Update: David writes that this isn't identical to his sproc...perhaps because it returns the lines as 'records' to preserve formatting? If you want to see the results in a more 'natural' format, you can use Ctrl-T first (output as text) and it should print it out exactly as you've entered it. If you are doing this in code, it is trivial to do a foreach to put together your results in exactly the same way.
Update 2: This will provide the source with a "CREATE PROCEDURE" rather than an "ALTER PROCEDURE" but I know of no way to make it use "ALTER" instead. Kind of a trivial thing, though, isn't it?
Update 3: See the comments for some more insight on how to maintain your SQL DDL (database structure) in a source control system. That is really the key to this question.
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:
SELECT
NULL AS [Text],
ISNULL(smsp.definition, ssmsp.definition) AS [Definition]
FROM
sys.all_objects AS sp
LEFT OUTER JOIN sys.sql_modules AS smsp ON smsp.object_id = sp.object_id
LEFT OUTER JOIN sys.system_sql_modules AS ssmsp ON ssmsp.object_id = sp.object_id
WHERE
(sp.type = N'P' OR sp.type = N'RF' OR sp.type='PC')and(sp.name=N'#test___________________________________________________________________________________________________________________00003EE1' and SCHEMA_NAME(sp.schema_id)=N'dbo')
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 the StringCollection could have a GO 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.
using System.Data.SqlClient;
using Microsoft.SqlServer.Management.Common;
using Microsoft.SqlServer.Management.Smo;
…
string connectionString = … /* some connection string */;
ServerConnection sc = new ServerConnection(connectionString);
Server s = new Server(connection);
Database db = new Database(s, … /* database name */);
StoredProcedure sp = new StoredProcedure(db, … /* stored procedure name */);
StringCollection statements = sp.Script;
Use the following select statement to get the whole definition:
select ROUTINE_DEFINITION
from INFORMATION_SCHEMA.ROUTINES
where ROUTINE_NAME = 'someprocname'
I guess that SSMS and other tools read this out and make changes where necessary, such as changing CREATE to ALTER. As far as I know, SQL stores not other representations of the procedure.
I agree with Mark. I set the output to text mode and then sp_HelpText 'sproc'. I have this binded to Crtl-F1 to make it easy.
The Databse Publishing Wizard can dump the schema (and other objects) from the command line.
I just want to note that instead of using find and replace to change create procedure to alter procedure, you are just as well to use a drop, you can put it right at the top and it does require text searching.
IF exists (SELECT * FROM sys.objects
WHERE object_id = OBJECT_ID(N'sp_name')
and type in ('P','V') --procedure or view
)
DROP sp_name
GO
If you are sure it's there, I guess you could just drop it too, but I wouldn't recommend that. Don't forget the go, since create procedure must be the first and only statement in a batch.
Or the lazy approach:
IF OBJECT_ID(N'sp_name') is not null
DROP sp_name
GO
I saw a article via link.
There are four methods, I just did a short summary here for helping other programmers.
EXEC sp_helptext 'sp_name';
SELECT OBJECT_ID('sp_name')
SELECT OBJECT_DEFINITION(
OBJECT_ID('sp_name')
) AS [Definition];
SELECT * FROM sys.sql_modules WHERE object_id = object_id('sp_name');
To alter a stored procedure, here's the C# code:
SqlConnection con = new SqlConnection("your connection string");
con.Open();
cmd.CommandType = System.Data.CommandType.Text;
string sql = File.ReadAllText(YUOR_SP_SCRIPT_FILENAME);
cmd.CommandText = sql;
cmd.Connection = con;
cmd.ExecuteNonQuery();
con.Close();
Things to note:
Make sure the USER in the connection string have the right to alter SP
Remove all the GO,SET ANSI_NULLS XX,SET QUOTED_IDENTIFIER statements from the script file. (If you don't, the SqlCommand will throw an error).