When I have issued a
ALTER TABLE table DISABLE CONSTRAINT fk1
and when I then try to drop the table
DROP TABLE table
That the constraint is still checked even though it is disabled.
Have I missed something?
You have to drop the constraints as well in order drop a table. Try the following:
DROP TABLE someTable CASCADE CONSTRAINTS;
DISABLE CONSTRAINT works for update/insert statements.
See oracle help.
Disabling Constraints
To enforce the rules defined by integrity constraints, the constraints
should always be enabled. However, consider temporarily disabling the
integrity constraints of a table for the following performance
reasons:
When loading large amounts of data into a table
When performing batch operations that make massive changes to a table
(for example, changing every employee's number by adding 1000 to the
existing number)
When importing or exporting one table at a time
You are trying to drop your table. It is not designed to for this. You need to DROP CONSTRAINTs.
Related
I have 21 tables in my database. However, there are some issues with the table schema (as we are trying to improve our data model). I already referred this post but it is for SQL server.
Currently, just for validation purpose, I would like to upload data inside them.
However, some ill-defined constraints are causing trouble.
So, I would like to delete all constraints only (from all tables) like Foreign key, check , unique, PK, Index etc.
How can I do this?
Currently I tried the below
ALTER TABLE subject
DROP CONSTRAINT subject_details_pk CASCADE;
ALTER TABLE subject
DROP CONSTRAINT subject_foreign_fk CASCADE;
As you can see, I have to write line by line across different tables (and manually find out which table is parent and which table is child etc).
So, is there any other way to drop all constraints in a table? Like Drop cascade ?
Can help me with this?
I have a table with some bad data in SQL. this table has a lot of relationship with other tables and other tables have a lot of data so when I want to delete bad data it's very slowly and take lots of time to do. I think the cause of this problem is foreign key constraints. the main problem is how can disable all of the foreign key constraints from one table.
You have to disable check constraint:
SET FOREIGN_KEY_CHECKS=0;
Make sure to turn it back after your commands:
SET FOREIGN_KEY_CHECKS=1;
Disable constraint for one table:
alter table
table_name
DISABLE constraint
constraint_name;
Here is an example:
select 'alter table '||table_name||' disable constraint '||constraint_name||';' from user_constraints;
In postgres when I drop a table it is dropping all views that depend upon it. Is there a way to persist the views so that they dont get dropped
Note: the table will be regenerated on daily basis with new data.
From PostgreSQL documentation
DROP TABLE always removes any indexes, rules, triggers, and constraints that exist for the target table. However, to drop a table that is referenced by a view or a foreign-key constraint of another table, CASCADE must be specified. (CASCADE will remove a dependent view entirely, but in the foreign-key case it will only remove the foreign-key constraint, not the other table entirely.)
Try TRUNCATE TABLE / CREATE TABLE IF NOT EXISTS instead of DROP.
Is there a way to truncate tables with constraints ?
I tried to DEACTIvATE with this:
DECLARE #SQLtxt varchar(max)
SET #SQLtxt = '-- DESACTIVER LES CONTRAINTES' + CHAR(10)
SELECT #SQLtxt = #SQLtxt + 'ALTER TABLE [' + name + '] NOCHECK CONSTRAINT ALL;' FROM sys.tables
PRINT #SQLtxt
Of course, it didn't worked. I have to drop the constraint then recreate them ! The only way I could make it work is by extracting the script to drop and recreate the contraint.
Is there another way ? BTW I don't want to delete because it would use the Transaction Log.
Here is a script that may help you get going scripting out FK's. Script out your foreign keys.
I use a modified version to dump the constraint definitions into a temp table, then do the TRUNCATE magic and then recreate the constraints from the temp table. However, this is only for my own convenience when restoring the production database onto a non-production environment to get rid of most of the data. Not sure, I would use it in a production scenario though. I would rather prefer deleting in small batches knowing that everything is fully logged.
Btw, womb's reference to the SQL Server 2000 Books Online is a bit misleading. TRUNCATE TABLE has always been a minimally logged operation.
TRUNCATE TABLE removes the data by deallocating the data pages used to store the table's data, and only the page deallocations are recorded in the transaction log.
This is has specified more precisely in later versions of Books Online.
The TRUNCATE command will not work on tables with FK references. Straight from the documentation:
You cannot use TRUNCATE TABLE on a
table referenced by a FOREIGN KEY
constraint; instead, use DELETE
statement without a WHERE clause.
Because TRUNCATE TABLE is not logged,
it cannot activate a trigger.
You sort of answered the question yourself - if there's a foreign key referencing your table, SQL Server needs that information in the transaction log. Since TRUNCATE TABLE effectively bypasses the log, it's not allowed on tables referenced by foreign keys.
You'll either have to DROP the foreign key constraint, or use a DELETE statement.
It's only referencing (eg the REFERENCES bit) foreign keys you need to drop.
This should make it easier...
Straight out of the MSDN docs for Sql Server 2005:
You cannot use TRUNCATE TABLE on tables that:
Are referenced by a FOREIGN KEY constraint.
Participate in an indexed view.
Are published by using transactional replication or merge replication.
I want the effect of a TRUNCATE (specifically the fact that it resets IDENTITY type columns), but I can't use one in my case because my table is referenced by a foreign-key elsewhere in the database.
Update: This is for a testing configuration where I am clearing out the referencing table as well, so foreign-key integrity is a non-issue.
What other ways are there to get around this?
You can delete all the rows and then do a DBCC CHECKIDENT (Tablename, RESEED, 0) to reset the identity seed
But again DELETE is fully logged while TRUNCATE is minimally logged and will be many times faster
Another option is to drop the foreign key constrains then do a truncate and then recreating the foreign key constraints
The fact that it is refernced by a foreign key is the clue you need to not truncate a table or you would be creating orphaned records. This is why truncate table is not allowed if a foreign key exists.
The correct process is to first delete the refernced records, if any, then drop the FK constraint, then truncate the table then reinstate the fk constraint. If you skip step one, you will create a data integrity nightmare where the record pointing to oldid 100 is not pointing to the new record that happens to get assigned to 100 and it isn;t the record it should match to.
You can drop the foreign key, truncate the table, and then recreate the foreign key.
You will need to drop the constraint, trunc the table, and then add the constraint back. However, you should be very careful with this. If there are rows in the table that you are dropping the FK reference to you will not be able to add it until those rows are deleted or the FK column in the other table is clear.