SET CONSTRAINT ALL DEFERRED
Posted in 1994
Topics: Triggers, Constraints & Referential Integrity
Subject: SET CONSTRAINTS ALL DEFERRED We are upgrading from 4.0-SE to 5.00-SE and analyzing use of referential constraints for our next release of application packages. The applications are developed in C with a Vermont Views user interface, running on a UNIX System V Release 3.2 platform. The version 4.0 referential integrity was protected by a complex utility that used our own referential constraint table. One function of this utility is a "cascading update" in which the primary and foreign keys (respectively) of a parent and child record are changed in a single transaction. The "RefKey" table may specify that multiple child and/or grandchild tables be updated as well. Now to version 5.0. It is not possible to update either the parent or the child record without violating the referential constraints. 5.0 Online recognizes this and allows the constraint checking to be deferred until the transaction is committed. Why doesn't Standard Engine allow this? The apparent workaround is to insert the new parent, update the child, and delete the old parent, but this is a kluge. It also means an expensive rewrite of the version 4.0 utility function. Can anyone suggest other ways around this limitation - perhaps some 5.0 feature we aren't aware of? Any help will be appreciated. Thanks. Mike Dwyer miked@ftc.scs.ag.gov