Our HSQLDB database has a FK constraint from the PAYMENTS table to the USERS table. What we did wrong here was create a constraint without giving it a specific name. This causes HSQLDB to generate a name for you, e.g. SYS_FK_10985.
What I did was write a custom change set for Liquibase that will find the name of the index and drop it. What the script does is pretty simple:
SELECT constraint_name FROM INFORMATION_SCHEMA.CONSTRAINT_COLUMN_USAGE WHERE TABLE_NAME= 'PAYMENTS' AND COLUMN_NAME= 'USER_ID';
If found, it is dropped by the following query executed in that same change set:
ALTER TABLE PAYMENTS DROP CONSTRAINT SYS_FK_10985;
The patch is executed successfully and the drop constraint command is added to the .log file of HSQLDB, however, when we then want to run the HSQLDB instance it throws an error saying the object could not be found.
The log file looks as follows:
The major problem is that the wrong index (a non-existent one) is dropped in the log file, which naturally causes HSQLDB to throw an exception. What is even worse: when the exception occurs, everything after that line is deleted from the log file and not even stored in the .data file.
Is it possible the constraint name changes causing the change set to get a wrong name?
You need to perform a CHECKPOINT right after this operation, or any series of structural changes.
The CHECKPOINT persists the changes into the .script file and deletes the .log file, avoiding the issue to arise.
Related
I added a simple check constraint to a table that contained some rows violating the constraint; I was expecting to be blocked by the engine due to an integrity check of old data but the schema was saved without warning. The constraint works as expected on new insertions or updates. Is it the expected behavior?
I'm using: XAMPP 3.3 (Windows 10), MariaDB 10.4.21, and SQLYog community edition as frontend
Yes this is expected behaviour as a CHECK constraint will
Before a row is inserted or updated, all constraints are evaluated in the order they are defined.
manual
As the old data are already inserted you will not get a an error message of a violation.
You can run a SELECT to check for all violations and update them accourding to a plan, or or could rename the old table create a new one with the old name and insert all data, this will stop when you hit a constraint, but the forst way is more secure
I've got a postgres database that I'm trying to clean up with drop schema public cascade. The data on it is not that important and I never made any backups. I'm just trying to rebuild it. However, it seems an error I made earlier is causing the drop command to fail.
When I run drop schema public cascade, I get a
ERROR: cache lookup failed for constraint XXXXX. I checked pg_constraints and it doesn't exist. It's probably linked to a table/index that doesn't exist anymore. Is there anyway I can get rid of this persisting/non-existing constraint so I can cleanup the database?
Perhaps it is enough to remove the dependency:
DELETE FROM pg_depend
WHERE objid = XXXXX;
On extension update, instead of using update SQL schema I have given a custom button like fix database under that extension. It working fine. Custom script executes from same schema folder structure i.e. "/sql/updates/mysql"
But some DDL commands are not working like INSERT, ALTER for adding primary key for already existing table, DROP to delete table.
I have checked the MysqlChangeItem.php file (using Joomla 3.8.10) under "libraries/src/Schema/ChangeItem" & found the different DDL commands which are handled but does not found about INSERT/adding primary key for existing table/drop table.
Can you please suggest the solution
I'm trying to update a target database with SQL Server Data Tools, using the Publish option. I've got both pre-deployment and post-deployment scripts with custom instructions.
Here's the problem: SSDT tries to drop an index numero from my target that doesn't exist in my reference schema, but fails because it is being used for foreign key enforcement by constraint fk_numero. This foreign key is being dropped later in the script since there's another change to be made on this table.
I have considered dropping fk_numero in my pre-deploy script, but it would fail anyway because of the DROP CONSTRAINT fk_numero that is called later in the generated script: since SSDT doesn't write IF EXISTS tests before dropping a constraint, it fails when trying to delete something that doesn't exist.
I have also tried to disable all foreign keys in my pre-deploy script with a NOCHECK CONSTRAINT ALL, hoping I'd then be able to drop my index, to no avail.
Is there an option in SSDT to specify whether you want it to generate DROP CONSTRAINT scripts? Or an option for instructions order? Or a way to hint to SSDT that it should test whether the constraint exists before trying to drop it?
You could try the "DROP objects in target but not in Project" option.
Are you using custom-made scripts to modify the schema?
I just encountered this issue when working with SSDT. Turns out it's a known bug, which was reported on Microsoft Connect. However, it doesn't seem to have been resolved.
UPDATE:
The May 2015 Update for SSDT includes a fix for this issue.
I'm in the process of testing a large number of schema changes to upgrade our db to run with the latest version of a packaged product we have.
At this point I'm not interested in the data contained in the db, only the schema (i.e. the tables, views, constraints, keys, stored procedures, etc.).
My testing entails running scripts, resolving errors, an re-running the scripts. If I want to re-run the scripts I need to first restore the db to get it back to a known state. Restoring the db is very time consuming as it has lots of data. I would like to "slim down" the db and remove as much data as possible. That way it will be quicker to restore the db and re-run my scripts
When I attempt to delete records from many of the tables ("delete from table-name") I run into constraint errors and the command stops.
Is there a way to allow the command to continue and, in effect, delete all the records in the table where there aren't constraint issues? In other words I'd like the command to ignore errors and continue to delete all the records it can.
Any Suggestions would be greatly appreciated.
Byron above makes a good point; you can disable FOREIGN KEY or CHECK constraints with the ALTER TABLE command:
ALTER TABLE TableName NOCHECK CONSTRAINT ALL
Then do your work, and when finished,
ALTER TABLE TableName CHECK CONSTRAINT ALL
to re-enable constraints. Be careful, though: if you leave your data in an inconsistent state that violates constraints once you re-enable them, future updates can fail due to constraint errors.
Sources:
http://weblogs.sqlteam.com/joew/archive/2008/10/01/60719.aspx
http://technet.microsoft.com/en-us/library/ms190273.aspx