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;
Related
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.
On dropping a unique constraint, following error occurs,
ORA-04098: trigger 'SYS.XDB_PI_TRIG' is invalid and failed re-validation
Having no permission to recompile this trigger.
What could be the problem here and is there any way we can solve this?
This error reflects a compilation/authorization failure for a mentioned trigger. This trigger was invalid so failed to be retrieved for execution. You can run
SHOW ERRORS TRIGGER SYS.XDB_PI_TRIG;
in order to have a bigger picture of that error.
Trigger may need to be recompiled. Running:
alter trigger SYS.XDB_PI_TRIG compile
will recompile this trigger.
Common case is when user has privileges only to run and not change respective triggers. In that case you may need to recompile the Trigger as SYSDBA.
I wouldthink that you may be dropping a primary key check what constraint your dropping. if your dropping a pk and its being used as a foreign key then this would invalidate the trigger.
Found a solution to this,
The XDB Schema is invalid for the Database. So we are unable to drop any objects in this Database. So making the XDB schema valid, has solved this problem.
Thanks for your answers!
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
I am using RedBean ORM. In order to create the schema I used the standard redbean approach of inserting data so that Redbean would auto-fit the schema to suit my needs. I put this in a script which would basically be used to build the schema when i need to initialize my database.
The problem is that RedBean keeps a row or 2 in each table (the ones that I initially inserted to get redbean to build the schema).
If it were a normal database, to erase all rows i would just drop the schema and rebuild it, but in this case that's not possible since the initial rows would still exist.
Unfortunately there isn't too much Redbean Q/A out there. Anyone know how I would do this using the Redbean interface?
I have tried
$listOfTables = R::$writer->getTables();
foreach($listOfTables as $table)
{
R::wipe($table);
}
Of course this doesn't work though. (It doesn't TRUNCATE the tables in the correct order so I get an error about another table using this key as a foreign link. It simply iterates in ABC order)
Fatal error: Uncaught [42000] - SQLSTATE[42000]: Syntax error or access violation: 1701 Cannot truncate a table referenced in a foreign key constraint (`redbeandb`.`research`, CONSTRAINT `research_ibfk_1` FOREIGN KEY (`ownEducationHistory_id`) REFERENCES `redbeandb`.`educationhistory` (`id`)) thrown in C:\Users\Rod\nginx-1.0.12\html\rb.php on line 105
If someone has a (redbean api) solution, it would be much appreciated. And hopefully this question can be beneficial to building up more RedBean Q/A here on Stackoverflow.
Use
R::nuke();
Yes, it will drop all tables but since RedBeanPHP creates all tables on the fly this is not a problem.
I know this is an old post but I figured I'd help out someone finding this today. You can tell mysql to ignore foreign key checks if you don't care about data integrity (plan on wiping all related tables).
R::exec('SET FOREIGN_KEY_CHECKS = 0;');
$listOfTables = R::$writer->getTables();
foreach($listOfTables as $table)
{
R::wipe($table);
}
R::exec('SET FOREIGN_KEY_CHECKS = 1;');