I created my table as BE Electrical. Later changed it's name to Be Electrical First. Now I can't
access What went wrong?
the table.
It is because of renaming your table has rendered its metadata useless
Use this for renaming
exec sp_rename 'Be Electrical','Be Electrical First'
instead of
exec sp_rename '[Be Electrical]','[Be Electrical First]'
After that you can use the table as intended.
For the current table that you have renamed you have to use the select query like
SELECT * FROM [dbo].[[Be Electrical First]]]
Note: try to avoid spaces in naming conventions in SQL server.
I created a global temp table like this -
CREATE TABLE ##BigTable
(Nos varchar(10) null)
Then try to rename the Nos column like this -
EXEC sp_RENAME '##BigTable.Nos' , 'Numbers', 'COLUMN'
I got the error -
Either the parameter #objname is ambiguous or the
claimed #objtype (COLUMN) is wrong.
Why could this be happening and how do I solve the problem ?
EXTRA stuff not exactly related to the question, but for reference.
I want to add this - I tried to create the global temp table using a fully qualified
name like this -
CREATE TABLE [NotMyTempDataBase].[dbo].[##BigTable]
(Nos varchar(10) null)
Then, I tried to rename it using -
EXEC tempdb.sys.sp_rename N'[NotMyTempDataBase].[dbo].[##BigTable].Nos',
N'Numbers', N'COLUMN';
Error - The qualified #oldname references a database other than the current database.
This is wrong. I realized that the temp table is created in the system database tempdb, even though you specify another DB name while creating it.
use this instead -
CREATE TABLE [tempdb].[dbo].[##BigTable]
(Nos varchar(10) null)
--SQL server message : Database name 'tempdb' ignored, referencing object in tempdb.
EXEC tempdb.sys.sp_rename N'[tempdb].[dbo].[##BigTable].Nos',
N'Numbers', N'COLUMN';
Ok, so the actual solution is:
EXEC tempdb.sys.sp_rename N'##BigTable.Nos', N'Numbers', N'COLUMN';
Since the #temp table (even a ##global temp table) lives in tempdb, you need to invoke sp_rename there.
But further questions to consider:
Why on earth are you using a ##global temp table? You know this effectively limits concurrency to ONE, right? What do you think will happen when two users call this code at the same time? Probably you want to use a #local temp table here, or maybe avoid #temp tables altogether.
Why do you have the need to change the column name halfway through the script? Either name it right in the first place, or keep referencing the old name. How is the script later on going to know you changed the name? For what purpose?
Also , This worked for me. It may helpful to someone
EXEC tempdb.sys.sp_rename N'#Tab1.Info', N'Numbers', N'COLUMN';
I recently upsized my MS-Access database to SQL Server and in the process successfully exported a bunch of tables.
However, now the imported tables are prefixed with MSH-CHAMBERS\mfanimpela which I assume is my username and this is the schema (or owner property).
While I have seen posts on changing EACH table schema to the desired 'dbo', I want a statement that can help me change ALL of my tables (since these are so many).
Please help - chagbert.
Use the sp_MSForEachTable procedure like this:
EXEC **sp_MSForEachTable** 'ALTER SCHEMA dbo TRANSFER ?'
-- in the above example dbo is the targeted schema where you want to place your tables
Google sp_MSForEachTable and use it to call sp_rename
You might need to do additional checks before you rename the table to avoid mistakes.
I renamed the table by sp_RENAME (SQL SERVER 2008)
sp_RENAME 'dbname.scname.oldtblname' 'dbname.scname.newtblnam'
The resulting message (it was in black color - so I get it as just a warning or successful message) was something like "Caution: Changing any part of an object name could break scripts and stored procedures."
So after this command my table with 45 million records just disappeared and I don't have any backup. This was a new table.
:) Do you guys have any idea about bringing my table back? :)
p.s. Yeah, my smile is not ":(", because when the seriousness of the problem goes up the threshold, ":(" becomes ":)".
What does this say? SSMS does not refresh Object explorer automatically so it could be there
USE dbname
SELECT OBJECT_ID('scname.newtblnam')
sp_rename says
You can change the name of an object
or data type in the current database
only. The names of most system data
types and system objects cannot be
changed.
You specified dbname so it's possible you have an object [dbname.scname.newtblnam] in dbo schema (or similar)
And did you do a backup first? Best practice before any (formal) schema changes, y'know
FWIW, I've never lost a table or other object using sp_rename
Faced that awful bug too, here is the solution:
--original
sp_RENAME 'dbname.scname.oldtblname', 'dbname.scname.newtblnam'
--workaround
sp_RENAME 'dbname.scname.[dbname.scname.newtblnam]','oldtblname'
name in [] is actually your TABLE name after sp_rename, to make SQL server to understand it put it in square brackets.
I found this a little unclear, but reading the docs for sp_rename reveals that
exec sp_rename 'udt.TenorSymbol_t_temp', 'udt.TenorSymbol_t', 'USERDATATYPE'
will create a type
udt.udt.TenorSymbol_t
So to create the type in the correct schema, don't specify the schema on rename
exec sp_rename 'udt.TenorSymbol_t_temp', 'TenorSymbol_t', 'USERDATATYPE'
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/