While selecting the sp name by using Rename, i wrongly press 's' and press tab. Then it is renamed wrongly. I don't know the Sp Name. How do i get the old sp name. Kindly suggest me.
From MSDN I found in sp_rename (Transact-SQL)
Renaming a stored procedure, function, view, or trigger will not
change the name of the corresponding object name in the definition
column of the sys.sql_modules catalog view. Therefore, we recommend
that sp_rename not be used to rename these object types. Instead, drop
and re-create the object with its new name.
I have tested the same and I got old object name.
GO
CREATE PROCEDURE PROC_MY_SP
AS
BEGIN
SELECT 1 AS COL
END
GO
SELECT OBJECT_ID('PROC_MY_SP') --789786071
GO
SELECT * FROM sys.sql_modules WHERE OBJECT_ID('PROC_MY_SP')= OBJECT_ID
GO
sp_rename 'PROC_MY_SP', 'PROC_YOUR_SP'
GO
SELECT OBJECT_ID('PROC_YOUR_SP') --789786071
--Changing the SP Name wont change the objectID
GO
SELECT definition,* FROM sys.sql_modules WHERE OBJECT_ID=789786071
--Or Simply pass your new sp name
SELECT definition, * FROM sys.sql_modules WHERE OBJECT_ID('PROC_YOUR_SP')= OBJECT_ID
Here the definition column showing the old sp name only.
Related
Some time ago the procedure ALF_GetPopulationForPolygon_2_old was created. Then in SSMS, it was renamed (right mouse button -> rename) to the procedure ALF_GetPopulationForPolygon_2_old_FOR_DELETE_20170504. Renaming passed normally, but as a result, the query:
SELECT
sm.definition
FROM
sys.objects AS o
INNER JOIN sys.sql_modules AS sm
ON ( 1 = 1 )
AND ( sm.object_id = o.object_id )
WHERE
( 1 = 1 )
AND ( o.name like 'ALF_GetPopulationForPolygon_2_old_FOR_DELETE_20170504' )
And calling the stored procedure:
EXEC sp_helpText 'ALF_GetPopulationForPolygon_2_old_FOR_DELETE_20170504'
Return the following text:
...
CREATE PROCEDURE [dbo]. [ALF_GetPopulationForPolygon_2]
...
Those show the OLD(!) name of the procedure. Do you have any idea what this is caused, and how can this be fixed?
You shouldn't rename your objects for at least two reasons.
If you'd use a T_SQL command instead of GUI (all that you "clicks" in Management Studio produces T-SQL coede behind the scenes), you'd get a warning, the same you can see in BOL article:
sp_rename (Transact-SQL)
CAUTION Changing any part of an object name can break scripts and stored
procedures. We recommend you do not use this statement to rename
stored procedures, triggers, user-defined functions, or views;
instead, drop the object and re-create it with the new name.
And it was the first reason against renaming.
Scrolling the article find the Remarks section:
Renaming a stored procedure, function, view, or trigger will
not change the name of the corresponding object name in the definition
column of the sys.sql_modules catalog view. Therefore, we recommend
that sp_rename not be used to rename these object types. Instead, drop
and re-create the object with its new name.
And this was the second.
So when you want to rename your procedure you should script your procedure as CREATE and change the procedure name, doing so you recreate your proc with the new name and then you can drop the old one
I have 10 stored procedures they are different with their definition in sys_modules. I find them with this query:
select
b.definition, a.name
from
sysObjects a
left outer join
sys.sys_modules b on b.id = a.object_id
where
b.definition not like '%' + b.name + '%'
Could someone tell me why this happens?
It's the second time I faced this problem.
This happens if you use sp_rename and is explicitly called out in the documentation
Renaming a stored procedure, function, view, or trigger will not
change the name of the corresponding object name in the definition
column of the sys.sql_modules catalog view. Therefore, we recommend
that sp_rename not be used to rename these object types. Instead, drop
and re-create the object with its new name.
Note that the rename functionality in SSMS object explorer does in fact call this procedure.
Use INFORMATION_SCHEMA.ROUTINES and get the ROUTINE_DEFINITION column for stored procedures
Some time ago the procedure ALF_GetPopulationForPolygon_2_old was created. Then in SSMS, it was renamed (right mouse button -> rename) to the procedure ALF_GetPopulationForPolygon_2_old_FOR_DELETE_20170504. Renaming passed normally, but as a result, the query:
SELECT
sm.definition
FROM
sys.objects AS o
INNER JOIN sys.sql_modules AS sm
ON ( 1 = 1 )
AND ( sm.object_id = o.object_id )
WHERE
( 1 = 1 )
AND ( o.name like 'ALF_GetPopulationForPolygon_2_old_FOR_DELETE_20170504' )
And calling the stored procedure:
EXEC sp_helpText 'ALF_GetPopulationForPolygon_2_old_FOR_DELETE_20170504'
Return the following text:
...
CREATE PROCEDURE [dbo]. [ALF_GetPopulationForPolygon_2]
...
Those show the OLD(!) name of the procedure. Do you have any idea what this is caused, and how can this be fixed?
You shouldn't rename your objects for at least two reasons.
If you'd use a T_SQL command instead of GUI (all that you "clicks" in Management Studio produces T-SQL coede behind the scenes), you'd get a warning, the same you can see in BOL article:
sp_rename (Transact-SQL)
CAUTION Changing any part of an object name can break scripts and stored
procedures. We recommend you do not use this statement to rename
stored procedures, triggers, user-defined functions, or views;
instead, drop the object and re-create it with the new name.
And it was the first reason against renaming.
Scrolling the article find the Remarks section:
Renaming a stored procedure, function, view, or trigger will
not change the name of the corresponding object name in the definition
column of the sys.sql_modules catalog view. Therefore, we recommend
that sp_rename not be used to rename these object types. Instead, drop
and re-create the object with its new name.
And this was the second.
So when you want to rename your procedure you should script your procedure as CREATE and change the procedure name, doing so you recreate your proc with the new name and then you can drop the old one
I am curious whether I can drop multiple procedures by simple using "%"?
Like:
DROP constantName%
When I use DROP in the Management studio, it looks like that:
/****** Object: StoredProcedure [dbo].[x] Script Date: 02/02/2010 09:36:25 ******/
IF EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].[x]') AND type in (N'P', N'PC'))
DROP PROCEDURE [dbo].[x]
Why it is checking the object ID when I am dropping this particular object?
The OBJECT_ID returns the database object identification number of a schema-scoped object. In your code it is checking it inside an IF EXISTS, so that it will only DROP the stored proc if is present in the database.
You could just have DROP PROCEDURE proc_name, but you could end up getting an error if the procedure does not exist. Its just good practise to check before you remove.
Tables, View, Stored Procs etc all have an OBJECT_ID as a key identifier.
I do not believe you can drop mutiple stored procedures using a LIKE. (Though i;m not 100% certain on that)
I think SQL was designed with this limitation, the drop procedure command needs a string constant. You can't pass a variable as an argument either, it just gives a 'incorrect syntax' error when you do.
Also the OBJECT_ID function only returns a valid id of objects the user owns, or has permission to. So OBJECT_ID is used because it performs the security validation.
Deleting with just "WHERE name = 'object_name'" could also work, but only if the user has permission for that object.
I am afraid you cant use the like syntax in DROP, below the simple one liner to drop multiple procedures.
DROP PROCEDURE testest,testest1
And for your 2nd question. There are scenarious we can create Storedprocedure that can be accessible only to the particular role.
create proc dbo.testest
as
begin
select 1
end
query sys.objects with the role value
select * from sys.objects where name ='dbo.testest'
it returns null
select * from sys.objects where name ='testest'
now it works
sys.objects catalog view stores the information without the role names (only just names). But using OBJECT_ID, we can retrieve the role specific info
select OBJECT_ID('dbo.testest') //works
select OBJECT_ID('testest') //works
hope you can understand now.
Is there a way when executing a stored procedure in Management Studio to get the data types of the result sets coming back? I'm looking for something like functionality of when you pass a table name to sp_help
You do get to look at the types though, if you call the stored procedure via ADO, ADO.NET, ODBC or the likes: The resulting recordsets have the type information you are looking for. Are you really restricted to Management Studio?
Your best bet would be to change the stored procedure to a function. But that only works if your environment allows it.
No easy way comes to mind without parsing syscomments to see what it's querying from where. If you can edit the SP to select XML, you can append XML_INFO to the query to get the schema back.
Actually, you can do it from within an SP:
EXEC ('if exists (select * from sys.tables where name = ''tmp_TableName'') drop table tmp_TableName')
EXEC ('select * into tmp_TableName from MyTable')
-- Grab the column types from INFORMATION_SCHEMA here
EXEC ('if exists (select * from sys.tables where name = ''tmp_TableName'') drop table tmp_TableName')
Although, I think there must be a better way.
It's not the most elegant solution, but you could use OPENROWSET to put the stored proc results into a table, then use sp_help to get a description of it.
eg
select * into tmp_Results
from openrowset( 'SQLOLEDB.1'
, 'Server=your_server_name;Trusted_Connection=yes;'
, 'exec your_stored_proc')
exec sp_help 'tmp_Results'
drop table tmp_Results
You could always use an actual table that is garrenteed to be unique. It's a kludge, but it's an option. This will not work inside a stored proc though.
if exists (select * from sys.tables where name = 'tmp_TableName')
drop table tmp_TableName
go
select * into tmp_TableName from MyTable
--do some stuff
go
if exists (select * from sys.tables where name = 'tmp_TableName')
drop table tmp_TableName
go