Shruthi A <shruthi.iisc@gmail.com> wrote:
> Thanks people, but the trigger doesnt really solve my problem. You see,
> there is actually a CHAIN of dependencies where B references A, C references
> B, D and E reference C and so on... So if i start writing triggers for all
> these, there'll be a huge process to follow. I'm not strictly against it, i
> might use it as a last resort, but i'm asking if a simple DML statement
> would solve my problem.
> Dear Shoaib, I did mention in a note that I don't want to recreate the 2
> tables with the 'on delete cascade' clause. The tables are ALREADY created
> and populated. And they are huge. So i cannot afford to drop and recreate
> them. I want an option in DML only. If that is possible that is.
You don't have to drop and recreate them, you could just
temporarily change the foreign key definition (untested):
| BEGIN WORK;
| ALTER TABLE B DROP CONSTRAINT B_z_FKey;
| ALTER TABLE B ADD CONSTRAINT B_z_FKey FOREIGN KEY(z) REFERENCES A(x) ON DELETE CASCADE;
| DELETE FROM A WHERE x = 'your x';
| ALTER TABLE B DROP CONSTRAINT B_z_FKey;
| ALTER TABLE B ADD CONSTRAINT B_z_FKey FOREIGN KEY(z) REFERENCES A(x) ON DELETE NO ACTION;
| COMMIT WORK;
But obviously this is no better than a simple "DELETE FROM B
WHERE z = 'your x';" as you still have to name the dependen-
cy chain yourself.
You can query the information_schema to build this chain
(e. g. cf.
<URI:http://sqlserver2000.databases.aspfaq.com/schema-how-do-i-find-all-the-foreign-keys-in-a-database.html>),
but I would invest more time in rethinking your processes.
Tim