As the title says, I cannot drop or alter a column in SQL Azure. I wanted to change its datatype from int to tinyint. I did specify tinyint, but it seems Azure overrode that.
I've tried via the Management Console as well as from SSMS.
I found the following SO question, but importantly, my column is not a primary/foreign key and is not even used in an index.
SQL Azure - Could not able to alter column type
In Aure Management Console, I get the following error
<?xml version="1.0" encoding="utf-8"?><m:error xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata"><m:code>InternalError:7752a6bb-a244-f1a0-221b-b9c482ae6680</m:code><m:message xml:lang="en-US">An error was encountered while applying the changes.
An exception occurred while executing the Transact-SQL statement: ALTER TABLE [dbo].[xxxxx] DROP COLUMN [EmailFrequency2].
The object 'ColumnDefault_b0898c7d-0fb6-4466-8894-1325eb8c4efd' is dependent on column 'EmailFrequency2'.
ALTER TABLE DROP COLUMN EmailFrequency2 failed because one or more objects access this column.</m:message></m:error>
I did try googling "InternalError:7752a6bb-a244-f1a0-221b-b9c482ae6680" but got zero hits.
I've tried disable constraints when attempting to alter the table (to change the datatype from int to tinyint):
ALTER TABLE [dbo].[xxxxx] NOCHECK CONSTRAINT ALL
ALTER TABLE [dbo].[xxxxx] ALTER COLUMN [EmailFrequency] TINYINT NULL
ALTER TABLE [dbo].[xxxxx] NOCHECK CONSTRAINT ALL
But I get basically the same error:
Msg 5074, Level 16, State 1, Line 2
The object 'ColumnDefault_871cbb52-f294-4a57-9c51-b8fd435d0d59' is dependent on column 'EmailFrequency'.
Msg 4922, Level 16, State 9, Line 2
ALTER TABLE ALTER COLUMN EmailFrequency failed because one or more objects access this column.
I can't find any reference to the ColumnDefault_xxxx-GUID-xxx object anywhere
Can anyone suggest how I could get around this constraint? I was able to rename the table, but not drop it or change the datatype.
The default value is a constraint you have in place, you have to delete it first:
ALTER TABLE xxxxx DROP CONSTRAINT <name of your default here>
I used code first migrations, and in my case, I was trying to make a property of a class not null by using [Required] annotation above the property. This kept giving me the JSON response "An error has occurred" when I tried to reach my endpoints.
After some time I realized I had records in that particular table, which had no value for the property I was trying to make not null, hence the error. Stupid mistake. I hope I can save someone from hours of googling. Haha.
Related
i'm having trouble with running multiple ALTER commands in a single query.
Whenever im trying to run the following code :
ALTER TABLE Book$
ALTER COLUMN PID INT NOT NULL
ALTER TABLE Book$
ADD CONSTRAINT pk_book PRIMARY KEY(PID)
I get an error :
Cannot define PRIMARY KEY constraint on nullable column in table 'Book$'.
But if i run the queries separately , first :
ALTER TABLE Book$
ALTER COLUMN PID INT NOT NULL
And then :
ALTER TABLE Book$
ADD CONSTRAINT pk_book PRIMARY KEY(PID)
Everything seems to work just fine.
What am i doing wrong? Thanks!
Add GO(batch separator) in between to fix the problem
ALTER TABLE Book$
ALTER COLUMN PID INT NOT NULL
GO
ALTER TABLE Book$
ADD CONSTRAINT pk_book PRIMARY KEY(PID)
Without GO the entire script will be considered as single script
I'm not sure which database you are using. To explain what is happening, though, you need to understand two phases of statement processing: Compilation and Execution.
The Compilation phase reads the statement and defines the execution plan. The Execution phase then runs the plan. Nothing about the table changes just because a statement is compiled.
What is happening is that the two statements are compiled and then executed. When the second is compiled, nothing has changed (well, except for the fact that the first statement's execution plan is stored somewhere). Hence, you are getting a compilation error.
When you run the two separately, the changes from the first take place and then the second does not generate an error.
in orther to get a column similar to the mysql ENUM type, I wrote a sql query as follows
ALTER TABLE [DbName].[dbo].[MediaContent]
ADD MediaType nvarchar(50)
check(MediaType in ('audio','video','song','other'))
this worked as wished(for test): But now I want to delete this column without success. It seems like there no way to directly delete a column which has a constraint up on it.
How can I solve this issue? I want to delete this column and create another one.
here is the error message I get while the deletion
The object 'CK__MediaCont__Media__14270015' is dependent on column 'MediaType'.
ALTER TABLE DROP COLUMN MediaType failed
because one or more objects access this
column. (Microsoft SQL Server, Error: 5074)
The object referenced in the error message is the name of the constraint. You should be able to use the follow:
ALTER TABLE [DbName].[dbo].[MediaContent]
DROP CONSTRAINT CK__MediaCont__Media__14270015
You need to first drop the check constraint mentioned in the error message since that's stopping you from dropping the column. Following that you may drop the column.
Drop the constrain first then drop the column ,it will work
I have a database that I migrated from MySql using SQL Server Migration Assistant and it is now stored in Azure.
SSMA apparently generated a new primary key column, named ssma$rowid, for one of the tables. I am trying to change the PK back to Card_Key, but I am getting the following error:
An error was encountered while applying the changes.
An exception occurred while executing the Transact-SQL statement:
ALTER TABLE [carddb].[Cards] ALTER COLUMN [Card_Key] INT NOT NULL.
The index 'Card_Key' is dependent on column 'Card_Key'.
ALTER TABLE ALTER COLUMN Card_Key failed because one or more objects
access this column.
How can I make Card_Key the PK again?
The easiest might be to create a new table [cards2] with the correct primary key and copy your data from [cards] into the new table (just run a INSERT INTO cards2 ... SELECT ... FROM cards). Once that's done, you can drop (or rename to [cardsold] be on the safe side) the original table [cards], and rename the new table as [cards]: sp_rename cards2, cards
This should work.
I'm trying to drop a constraint on a DB table, something like:
ALTER TABLE MyTable drop CONSTRAINT FK_MyTable_AnotherTable
But the execution just runs and runs. If I stop it I see:
Msg 3727, Level 16, State 0, Line 2
Could not drop constraint. See previous errors.
Web search throws up various pages but note that the constraint is properly named and I am trying to remove it using the correct name
I was having the same issue on SQL Server 2008 R2, I solved my problem with below line hopefully it will work for someone else as well :)
Alter Table [Table Name]
DROP Column [Column Name]
Found a way to sort this, although I don't understand why it was necessary.
Have been able to drop the constraint by disabling it first:
ALTER MyTable NOCHECK CONSTRAINT FK_MyTable_AnotherTable
The drop then completes fine
Would still welcome any comments on the reason why this is necessary
Verify that you've not already dropped the constraint, like:
SELECT OBJECT_ID('FK_MyTable_AnotherTable')
If this returns null, your constraint no longer exists. That would explain the error message.
I had same problem.
The reason was that I made a mistake in my cursor statement, which was iterating some constraint I was to drop.
So this error occurred when the constraint was actually removed in the same transaction. Then I did a rollback and checked if it existed: it did (of course, after rollback!).
Check if it really exists at the moment of dropping.
I'm trying to change the size of a column in sql server using:
ALTER TABLE [dbo].[Address]
ALTER COLUMN [Addr1] [nvarchar](80) NULL
where the length of Addr1 was originally 40.
It failed, raising this error:
The object 'Address_e' is dependent on column 'Addr1'.
ALTER TABLE ALTER COLUMN Addr1 failed because one or more objects access
this column.
I've tried to read up on it and it seems that because some views are referencing this column and it seems that SQL Server is actually trying to drop the column that raised the error.
Address_e is a view created by the previous DB Administrator.
Is there any other way I can change the size of the column?
ALTER TABLE [table_name] ALTER COLUMN [column_name] varchar(150)
The views are probably created using the WITH SCHEMABINDING option and this means they are explicitly wired up to prevent such changes. Looks like the schemabinding worked and prevented you from breaking those views, lucky day, heh? Contact your database administrator and ask him to do the change, after it asserts the impact on the database.
From MSDN:
SCHEMABINDING
Binds the view to the schema of the underlying table or tables. When
SCHEMABINDING is specified, the base
table or tables cannot be modified in
a way that would affect the view
definition. The view definition itself
must first be modified or dropped to
remove dependencies on the table that
is to be modified.
If anyone wants to "Increase the column width of the replicated table" in SQL Server 2008, then no need to change the property of "replicate_ddl=1". Simply follow below steps --
Open SSMS
Connect to Publisher database
run command -- ALTER TABLE [Table_Name] ALTER COLUMN [Column_Name] varchar(22)
It will increase the column width from varchar(x) to varchar(22) and same change you can see on subscriber (transaction got replicated). So no need to re-initialize the replication
Hope this will help all who are looking for it.
See this link
Resize or Modify a MS SQL Server Table Column with Default Constraint using T-SQL Commands
the solution for such a SQL Server problem is going to be
Dropping or disabling the DEFAULT Constraint on the table column.
Modifying the table column data type and/or data size.
Re-creating or enabling the default constraint back on the sql table column.
Bye
here is what works with the version of the program that I'm using: may work for you too.
I will just place the instruction and command that does it. class is the name of the table. you change it in the table its self with this method. not just the return on the search process.
view the table class
select * from class
change the length of the columns FacID (seen as "faci") and classnumber (seen as "classnu") to fit the whole labels.
alter table class modify facid varchar (5);
alter table class modify classnumber varchar(11);
view table again to see the difference
select * from class;
(run the command again to see the difference)
This changes the the actual table for good, but for better.
P.S. I made these instructions up as a note for the commands. This is not a test, but can help on one :)
Check the column collation. This script might change the collation to the table default. Add the current collation to the script.
You can change the size of the column in 3 steps:
Alter view Address_e and take in comment column /*Addr1*/
Run your script
ALTER TABLE [dbo].[Address]
ALTER COLUMN [Addr1] [nvarchar](80) NULL
Then again alter view Address_e, in order to uncomment column Addr1