I am trying to modify the data type on a number of columns from int to bigint using:
<modifyDataType tableName="ACCESS_HISTORY" columnName="ID" newDataType="${LongType}"/>
Where I have defined LongType to be:
<property name="LongType" value="bigint" dbms="mssql"/>
I noticed in the Liquibase JIRA (https://liquibase.jira.com/browse/CORE-1062) that there is a known issue from 2011 relating to the PKs and FKs that need to be dropped. Dropping and re-creating the keys isn't really an option for me.
The error I got was:
liquibase.exception.MigrationFailedExc
eption: Migration failed for change set ChangeColumnTypes.xml::4-4-060
-2::thof:
Reason: liquibase.exception.DatabaseException: Error executing SQL ALTER TA
BLE [dbo].[ACCESS_HISTORY] ALTER COLUMN [ID] BIGINT: The object 'PK_Access_Histo
ry' is dependent on column 'ID'.:
Caused By: Error executing SQL ALTER TABLE [dbo].[ACCESS_HISTORY] ALTE
R COLUMN [ID] BIGINT: The object 'PK_Access_History' is dependent on column 'ID'
I was wondering if anyone had got around this? Thanks in advance
I'm afraid to say that there is no way to currently do this unless you drop the PK constraint. It looks like the bug you're talking about though is scheduled to be fixed in version 3 of liquibase, however there is no release date for this version.
Sorry!
As Liquibase is open source you could always fix the bug yourself. :)
Related
i'm getting the above error when i try and run any alter table type script, even an add column script returns this error eg:
alter table up_retail add StockGroupID int null
running the above will return the above error, i have tried restarting sql, restore ansi settings etc, does anyone have any advice on what might be causing this?
UPDATE:
when i try and drop constraints as per
ALTER TABLE [dbo].[ZSeeAlso] DROP CONSTRAINT [FK_ZSeeAlso_Performers]
i get this:
Incorrect syntax near 'dbo'.
again, any ideas what would cause this?
** UPDATE 2 **
for everyone checking this is the only thing in my query window, here is my ssms:
Your query is okey , try to Use YourDB that contains the table up_retail Not Master like this :
Use YourDB
Alter Table up_retail Add StockGroupID int null
Go
after trying everything i can think and that, that was suggested in here, i basically ended up re-installing sql and that seems to have fixed. it looks like the syntax engine or sql itself became corrupt for some reason
thanks all for the suggestions
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.
On Oracle 11g XE I ran the following statement:
alter table le_customer drop column profile_id;
and then removed the equivalent column reference from a simple view on the table and recompiled the view successfully.
I then ran some PL/SQL that referenced the view and I started getting getting
ORA-00600: internal error code, arguments: [kkdcsaccc2], [], [], [], [], [], [], [], [], [], [], []
(however if I changed the PL/SQL to reference the table directly then the code worked)
I have dropped and recreated the view and also run "alter table le_customer move ..." successfully, however the error continues to occur with 100% consistency.
I have shut the database down and run dbv against the database .dbf files - no errors were reported.
I am running on a VM so I rolled the code back and removed the profile_id column reference from the view without physically removing the column from the le_customer table ...and everything then worked fine with my code. Then I ran alter table le_customer drop column profile_id; again and immediately the ORA-00600 re-occurred.
I rolled the VM back again then ran
alter table le_customer rename column profile_id to donald_duck;
.......then tested and everything worked fine.
I then ran
alter table le_customer drop column donald_duck;
...then tested again and got the ORA-00600 immediately.
So I am very sure that the problem is being caused by the "alter table le_customer drop column ;" statement and i am lost as to how to resolve it.
So, if anyone has seen this or has any ideas regarding a test / workaround I would greatly appreciate any info you are able to share - thanks!
My previous conclusion was incorrect ...as I have again seen the exact same problem, this time on 2 completely separate database builds. The problem table however remained the same one as before (ie. le_customer) and:
the schemas were identical on both databases
the identical query behaviour was consistent on both database
the query behaviour was consistent regardless of whether the simple
view or base table was queried
The query consistently succeeded when no where clause was present
the query consistently failed as soon as as a simple where clause
was added ie. "where id = 123"
failure occurred regardless of the where clause content ie. "where
code = 'ABC'" also failed
the "where clause" continued to cause query failure even after all indexes were
dropped from the table
...I began dropping constraints one by one from the table, rerunning the query each time
And on removing the following constraint, the query started working!
constraint le_cus_bus_case_chk check(allow_case_boo = 'F'
or
case_master_template is not null
)
A fairly innocuous constraint on the following 2 columns, where noticeably case_master_template is an xmltype stored "out of row"
...
allow_case_boo varchar2(1)
case_master_template xmltype
...
)
xmltype column case_master_template store as clob (disable storage in row)
To confirm this constraint to be the problem, on the other database deployment where the same behaviour was manifesting - and all indexes and constraints still existed on the table - , I dropped the above constraint only. Immediately the problem disappeared and the query started working reliably.
I then removed all constraints, indexes, foreign keys from the table other than this one, and the query continued to manifest the ORA-00600 reliably. On removing this constraint last, the ORA-00600 disappeared from both view and table query (regardless of where clause existence).
So while i have no visibility of the internal workings, I do believe that I have identified the culprit, and can fairly confidently provide the recommendation to others to first check constraints on xmltype type columns that may exist should ORA-00600 "kkdcsaccc2" appear. And I will be removing the constraint from the table.
I hope this proves useful to someone.
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've just had something very strange happen to me with a Firebird database.
I was trying to create a table, and the CREATE TABLE failed for some reason. But now it's stuck in a very strange state:
If I try to CREATE TABLE again with the same table name, it gives an error: the table already exists. But if I try to DROP TABLE that table, it gives an error: the table does not exist. Trying to SELECT * FROM that table gives the "table does not exist" error, and the name does not show up in the metadata query:
SELECT RDB$RELATION_NAME
FROM RDB$RELATIONS
WHERE RDB$SYSTEM_FLAG=0
So for some reason, the table really seems to not be there, but I can't create it because something somewhere indicates that it does exist.
Does anyone have any idea how to fix this? I've already tried closing all connections to that database, which has helped with inconsistency issues in the past, but this time it doesn't help.
You didn't give details about what was the error when you tried to create the table, so I cannot comment it. But RDB$RELATIONS is not the only system table affected when you create a table. Maybe you are now in an inconsistent situation where some information about that table exists in some system tables and doesn't exists in others.
Another option is corrupted indexes in the system tables, so the record is not there but the index think it still exists.
Try to do a backup/restore and see if it helps. It it doesnt work, try to search for records related to that "non created" table in the other system tables (RDB$RELATION_FIELDS, etc) and if you find any, try to delete them.
As a last option, you may create a new clean database with correct metadata and pump your data to it using IBDataPump.