I recently used - EXEC sp_rename '<source table name>', '<destination table name>' to rename an existing table and want to execute the same on one of our live server. Is there any issue in using this procedure to rename a table?. I am asking this because one of our DBA says there will be problems in using this procedure on live server.
Is nothing referencing the table you're renaming? That would be the only instance where I would think renaming the table would not have an impact. If the table was not referenced by anything however, what would be the purpose of the table?
you can read more about sp_rename here:
http://msdn.microsoft.com/en-us/library/ms188351.aspx
Specifically note the following:
Renaming an object such as a table or column will not automatically
rename references to that object. You must modify any objects that
reference the renamed object manually. For example, if you rename a
table column and that column is referenced in a trigger, you must
modify the trigger to reflect the new column name. Use
sys.sql_expression_dependencies to list dependencies on the object
before renaming it.
There is no major issue with renaming the table using that procedure. The only thing you need to remember is that while that command is being executed, the locks that are applied on that table won't allow you to query the data, but that should only take only a couple of milliseconds, so you should be fine.
P.S. Don't forget to modify your views, procedures, functions etc :)
Below is the only caution as described inthe microsoft official web site.
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.
More details at : http://msdn.microsoft.com/en-us/library/ms188351.aspx
EXEC sp_rename is recommended only when we sure that all the depended SP, View function are not get affected. Make sureyou changed or deleted the depended objects.
Perhaps your DBA can share the details of his/her concerns. Renaming a table will of course be a breaking change for any objects that reference the table so you'll need to perform due diligence to ensure dependent objects are changed to use the new name. The rename operation will also require a short schema modification lock and void existing referencing cached plans, so be aware of this if the table is heavily used.
Related
Last week, as a part of one requirement, I wrote a script to generate object definition for all database objects.
While testing, I found that for few stored procedures, [sys.objects].name was not matching with name in actual object definition (as returned by OBJECT_DEFINITION(Object_ID)). It was very strange and I saw it first time in life.
While thinking for what could be the reason of same, I found that it happens when we rename stored procedure from Object Explorer (View--> Object Explorer in SQL Server Management studio).
Just wondering, is there any way to retrieve actual object name (in this case, SP name)?
I had the same problem. It appears SP_RENAME doesn't update the object definition. From the sp_rename link, microsoft says:
Renaming a stored procedure, function, view, or trigger will not change the name of the corresponding object either in the definition column of the sys.sql_modules catalog view or obtained using the OBJECT_DEFINITION built-in function. 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 had a similar situation, where a stored procedure had been renamed using sp_rename. The new name used was iterative, with an extension of *_1. If the original name was 'MyProcedure', the new name would have been 'MyProcedure_1'.
'MyProcedure' represented the production code. 'MyProcedure_1' represented code that had been production code at one time, but was now obsolete. Indeed, 'MyProcedure_1' referenced objects that were no longer present in the database.
When looking at the name in sys.objects, the new name with the extension was there ('MyProcedure_1'), but the object_definition returned the old name ('MyProcedure'), but with the code for 'MyProcedure_1'.
This was discovered via a call to 'MyProcedure', which errored out, due to the missing objects.
The solution was to DROP 'MyProcedure_1', which effectively removed the object_id, and the erroneous object_definition, and reCREATE it. Of course we had to address the missing objects. And - we spread caution about using sp_rename for objects other than tables/columns.
I have a Sql Server 2008 database I inherited. A number of apps and SSIS packages work off that database. Not too long ago the scope of the database changed and a lot of new tables were added. As a result of this a lot of the table names (and even the database name itself) no longer make sense, resulting in a very confusing schema.
I could rename the tables straight away and change the apps and processes to use the new names but the chaos and downtime it would cause in the meantime would not be acceptable.
Is there a way I can add an alternate name for a table (like a permanent alias) that I could use to refer to either the new or old table name until all of my refactoring is complete?
Create a synonym first.
CREATE SYNONYM dbo.SensibleName FOR dbo.CrazyName;
Now find all the references to CrazyName in your codebase, and update them to reference SensibleName instead. Once you believe you have found them all, you can eventually run:
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
BEGIN TRANSACTION;
DROP SYNONYM dbo.SensibleName;
EXEC sp_rename N'dbo.CrazyName', N'SensibleName', N'OBJECT';
COMMIT TRANSACTION;
If you need to make column names more sensible, you'll have to do so using a view, as synonyms only cover a subset of database-level objects.
Some other info here.
You can rename it with sp_rename and then add synonym:
CREATE SYNONYM OldTableName FOR NewTableName
I know databases aren't supported by CREATE SYNONYM, but I'm looking to achieve the functionality this would provide.
We've got Database A which contains views to tables on Database B. The trouble is "Database B" isn't always called "Database B". We use database projects for deployments, which at the moment fall over with an "Invalid Object Name" error if there isn't a "Database B".
The workaround at the moment is to open up the .dbschema file and do a find and replace. I guess another option would be to create a load of table synonyms.
What's the best way of changing the database a number of views reference without changing each view individually?
Thanks
Synonyms are a good way to do this. You have to create the synonyms at the object level though (as you've discovered). An easy way to do this would be to write a script that runs through the list of tables in DatabaseB (from your example) and creates a synonym for each one in DatabaseA. Keep the name of the synonym the same so the code in your views doesn't have to change. For instance, you you have tbl_a, tbl_b, and tbl_c in DatabaseB, you'd want your script to eventually do the following:
create synonym [otherDb].[tbl_a] for [DatabaseB].[schemaB].[tbl_a]
create synonym [otherDb].[tbl_b] for [DatabaseB].[schemaB].[tbl_b]
create synonym [otherDb].[tbl_c] for [DatabaseB].[schemaB].[tbl_c]
Now, in your view code, you'll always use [otherDb].[tbl_a], [otherDb].[tbl_b], and [otherDb].[tbl_c]. Hope this makes sense.
Last year I helped my current client with the implementation of a very similar design. We wrote a set of functions and stored procedures which generate the views automatically. Whenever you need to change the target database it generates the code to drop and recreate all of the views.
The code wasn't too difficult. It just uses the system tables to generate view code. I also wrote a Powershell prototype that uses SMO to do the same thing. The key is to have it automated to the point of requiring a single call so that you can do it easily and accurately.
We also included an exception table that used a pattern match of tables to exclude from view generation. It included a schema column and a table name column, each of which accepted LIKE patterns, so you could put "my_schema" and "%" to exclude all tables in the my_schema schema.
One master stored procedure accepted a target database name and would generate the entire script. Once the script is generated you can run it in SSMS or have that part automated as well.
This whole thing would be even easier if you just wanted to generate synonyms. We were using views so that we could change column lists, etc. and have the view DB look different than the target DB where needed.
If we want to change the name of MyColumnName to MyAlteredColumnName...
...and we have a SQL Server 2008 table that looks like:
MyTable
MyColumnName
and a view that references the underlying column:
CREATE VIEW MyDependentView WITH SCHEMABINDING
AS
SELECT ..., MyTable.MyColumnName
We end up following this procedure:
Dropping the View
Altering MyTable.MyColumnName to MyTable.MyAlteredColumnName
Recreating the View with a reference to MyAlteredColumnName
We do this with migrator dot net.
Is there a better way to do this? Is there T-SQL that will alter a view column name? Or any support in SQL Server 2008 for automagically tying the columns together?
Without the use of a third-party tool, this is one of the only ways to do it. You can obviously also use ALTER VIEW instead of a DROP and CREATE.
It should be noted that Red-Gate makes a tool called SQL Refactor which will automate this sort of change (no I do not work for them). I'm sure there are other similar database refactoring tools out there.
Use sp_refreshview:
EXEC sp_refreshview #viewName
If you want to refresh all your views, you'll have to iterate over a loop of them, which means dynamic SQL.
And if you layered them (a view is dependent on another view - bad), you'll have to refresh the parent first...
If it's a SELECT * view, you can call sp_refreshview, as OMG_Ponies suggested. It will recompile the view and update the column metadata appropriately. This is one area where judicious use of SELECT * could have benefits, if used appropriately within a coherent scheme.
Otherwise, you must redefine the view. Any explicit references to the old column name will now raise an error.
Ah, one more alternative:
EXEC sp_rename 'MyTable.MyColumnName', 'MyAlteredColumnName'
ALTER TABLE MyTable ADD MyColumnName AS MyAlteredColumnName
EXEC sp_rename 'MyView.MyColumnName', 'MyAlteredColumnName'
It's a hack, and it's dangerous, since the stored view definition will now be out of sync with the view metadata. And you have littered the db with superfluous computed columns.
But it will work (until you forget what you did, or someone else has to maintain the system, and things start to break mysteriously).
I use a third party tool for this, it hasn't failed me yet. It's ApexSQL Refactor, here's the how-to tutorial
How to rename a column without breaking your SQL database
I'm attempting to rename a stored procedure in SQL Server 2008 with sp_rename system sproc. The third parameter is giving me difficulty though and I keep receiving the following error:
Msg 15249, Level 11, State 1, Procedure sp_rename, Line 75
Error: Explicit #objtype 'P' is unrecognized.
As the message indicates I'm passing in a P for the value of the parameter. I call the sproc like this:
EXEC sp_rename #objName = #procName, #newname = #WrappedName, #objtype = 'P';
I double checked the documentation which says this is the value from sys.objects. I ran the following to double check I wasn't going crazy
select * from sys.objects where name = 'MySprocName'
and indeed the type returned is P.
Does anyone know what I should pass here? I don't want to leave this empty since I'm creating a generic sproc to among other things rename arbitrary sprocs and if there is a name collision between a sproc and something else I don't want to have to worry about that.
Just omit the #objtype parameter (the default is null) and it will work.
EXEC sp_rename 'sp_MyProc', 'sp_MyProcName'
You will receive the following warning, but the procedure will be renamed
Caution: Changing any part of an
object name could break scripts and
stored procedures.
Like others stated, you should drop and recreate the procedure.
According to the docs, 'P' is not a correct option. You should try 'OBJECT' as that seems like the closest thing to what you're trying to do. But, you should heed this warning ...
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.
Also (from the same MSDN page):
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.
sp_rename does not support procedures:
Changes the name of a user-created
object in the current database. This
object can be a table, index, column,
alias data type, or Microsoft .NET
Framework common language runtime
(CLR) user-defined type.
Just create the new procedure with the same body and new name, then drop the old one.
I'm not sure about the #objtype variable, however I do know that renaming via sp_rename is bad.
When you create a stored proc, a record for it exists in sys.objects and the definition of the stored proc will be stored in sys.sql_modules.
Using sp_rename will only change the name in sys.objects, not in sys.sql_modules thus your definition will be incorrect.
The best solution is a drop & recreate
The third parameter(#objtype) is required when you want to rename a
database object other than a stored procedure. Otherwise it is
necessary to pass a third parameter. For example renaming a column
using sp_rename will look something like this.
USE AdventureWorks2012;
GO
EXEC sp_rename 'Sales.SalesTerritory.TerritoryID', 'TerrID', 'COLUMN';
GO
To rename a user-defined stored procedure using sp_rename,you can do something like this and it literally works
However it is not recommended by Microsoft, DB experts (and others here as well) to use this stored procedure as it will break things internally and might possibly incur unusual results later.Therefore it is bad. Here's what Microsoft has to say:
Renaming a stored procedure, function, view, or trigger will not change the name of the corresponding object either in the definition column of the sys.sql_modules catalog view or obtained using the OBJECT_DEFINITION built-in function. 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.
Renaming an object such as a table or column will not automatically rename references to that object. You must modify any objects that reference the renamed object manually. For example, if you rename a table column and that column is referenced in a trigger, you must modify the trigger to reflect the new column name. Use sys.sql_expression_dependencies to list dependencies on the object before renaming it.
You can read about it here: sp_rename (Transact-SQL)
There are two approaches to rename stored procedure.
Dropping and Recreating Procedure : The problem is it will lead to losing of permissions.
sp_rename of Procedure : Permissions will remain intact. The stored procedure will be renamed. But, sys.sql_modules will still be having the old definition.
I prefer the second approach. I followed the below steps:
Have copy of the stored Procedure content
Rename the stored procedure
EXEC sp_rename 'dbo.OldStoredProcedureName','NewStoredProcedureName'
GO
ALTER PROCEDURE to have the modified code of the procedure in the sys.sql_modules
ALTER PROCEDURE dbo.NewStoredProcedureName
...
Now, Stored procedure name is also updated and code is refreshed in sys.sql_modules and permissions are also intact.
In SQL 2000 days, it was safer to DROP/CREATE-- SQL used to let the meta data for the proc get out of synch when you use sp_rename.
The best way to find out how to do fancy DDL like that is to use SSMS to rename the object while a profiler trace is attached.
All that Valentino Vranken said is true. However bear in mind that when you drop and create a stored procedure, you lose all of your metadata. (Create_Date, Modify_Date etc.)
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.
This is also true. However I found that when you run the alter script after making the rename, it corrects the name in the definition in the modules.
I have wondered how the SSMS interface does all of this automagically without using T-SQL. (Perhaps it runs an alter script each time you rename an SP using the interface? I don't know.) It would be interesting is MS were to publish what is happening behind the scenes when you do a SSMS rename.
sp_rename only change the name of user created objects in database. Renaming a stored procedure 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 you do not rename this object type. Instead, drop and re-create the stored procedure with its new name.
even you should not use it use to rename to change to change the name of view, function,or trigger.
If you will try to use, it will rename it, but you will also get some warning message something like this:
Changing any part of an object name can break scripts and stored procedures.
For more information you can visit.
http://onlyforcoder.blogspot.in/2017/11/sprename-where-to-use-where-not-to-use.html
http://blog.sqlauthority.com/2008/08/26/sql-server-how-to-rename-a-column-name-or-table-name/