Jagar
asked on
Truncate Table
I'm trying to do a Truncate table
ALTER TABLE txoCheckDetails NOCHECK CONSTRAINT ALL
TRUNCATE TABLE txoCheckRequest
but am getting the following error.
Cannot truncate table 'txoCheckRequest' because it is being referenced by a FOREIGN KEY constraint.
So my questions is sinze I am diabling the only foriegn key constraint on the table it will not let me Truncate the table. I can do a DELETE on the table and remove everything, but how come I can't do a truncate.
ALTER TABLE txoCheckDetails NOCHECK CONSTRAINT ALL
TRUNCATE TABLE txoCheckRequest
but am getting the following error.
Cannot truncate table 'txoCheckRequest' because it is being referenced by a FOREIGN KEY constraint.
So my questions is sinze I am diabling the only foriegn key constraint on the table it will not let me Truncate the table. I can do a DELETE on the table and remove everything, but how come I can't do a truncate.
Anthony Perkins
Truncate Table does not log this is the reason it is a lot faster than Delete, also the reason whe you cannot use it on Foreign Keys: There could not be any rollback.
I meant where the table is referenced by a Foreign Key.
ASKER
is there any way I can disable the foreign keys? Before running the truncate statement
Enterprise manager - right click - display dependencies.
or
Enterprise manager - right click on any table - generate scripts - remove the drop and create options - select indexes, foreign keys, primary keys - script to single file then search the file for the table name.
or
Enterprise manager - right click on any table - generate scripts - remove the drop and create options - select indexes, foreign keys, primary keys - script to single file then search the file for the table name.
ASKER
I did that and there is only one table referencing that table.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
disagree - removing foreign key - truncating table - adding foreign key with nocheck is fater on a large table if dangerous.
I remove all foreign keys from the database then add them all after the truncate - but I only ever do this if I am clearing all tables - otherwise why have foreign keys, if you remove them to truncate a table then you may as well not have them and maintain integrity in the updates.
I remove all foreign keys from the database then add them all after the truncate - but I only ever do this if I am clearing all tables - otherwise why have foreign keys, if you remove them to truncate a table then you may as well not have them and maintain integrity in the updates.
I stand corrected. Thanks Nigel.
ASKER
OK so then how would you recommend that I accomplish the following task. Each night I need to rebuild 95% of table in my database from an Oracle database. The other 5% of the tables are very large and we only do INSERTS of the new information to that table.
Now I realize from what you are saying that I could use the delete statement or I could drop each foriegn key and rebuild them.
The problem with Deleting each table is I have do make sure and do them in a particular order, so that I drop the table that have no references and then work my way up. But this besides being a pain is not very pratical since someone could add a new foriegn key or something at a later date and then the whole thing would fail, since the order did not take this new on into account.
The problem with dropping each foriegn key and rebuilding them is basically the same if I don't know that a new one was added everything will again fail.
So how can I accomplish this.
Now I realize from what you are saying that I could use the delete statement or I could drop each foriegn key and rebuild them.
The problem with Deleting each table is I have do make sure and do them in a particular order, so that I drop the table that have no references and then work my way up. But this besides being a pain is not very pratical since someone could add a new foriegn key or something at a later date and then the whole thing would fail, since the order did not take this new on into account.
The problem with dropping each foriegn key and rebuilding them is basically the same if I don't know that a new one was added everything will again fail.
So how can I accomplish this.
How about this:
You have two types of table - one which gets rebuilt every night, one which remains.
Why not put them in different databases.
For the rebuild you can then drop all the tables and run the create script. Or hold an empty database backup and erstore it every night (need to kill connections though) Or use sql-dmo / dts to copy all objects from an empty database. Doesn't matter how you do it because this database isn't imoportant as it is not the source for any data.
Then you can access the database from the other database to extract. Means that the database which does hold data has permanent objects and is smaller - doesn't have all the deletes so won't get fragmented and will be easier to maintain.
You have two types of table - one which gets rebuilt every night, one which remains.
Why not put them in different databases.
For the rebuild you can then drop all the tables and run the create script. Or hold an empty database backup and erstore it every night (need to kill connections though) Or use sql-dmo / dts to copy all objects from an empty database. Doesn't matter how you do it because this database isn't imoportant as it is not the source for any data.
Then you can access the database from the other database to extract. Means that the database which does hold data has permanent objects and is smaller - doesn't have all the deletes so won't get fragmented and will be easier to maintain.
Thanks for the points, although I think Nigel may have helped you with a solution.
Anthony
Anthony