From ineyman@perceptron.com Wed, 28 Nov 2001 09:20:38 -0800 From: "Igor Neyman" Date: Wed, 28 Nov 2001 09:20:38 -0800 Subject: Re: Script to Disable Constraint, Change Value, then Enable Const Message-ID: MIME-Version: 1.0 Content-Type: text/plain Not good approach. Instead, use 'deferrable constraints, should work in your situation.   Igor Neyman, OCP DBAineyman@perceptron.com 
----- Original Message -----
From: David Wagoner To: Multiple recipients of list ORACLE-L Sent: Wednesday, November 28, 2001 11:24 AM Subject: RE: Script to Disable Constraint, Change Value, then Enable Const I can see the confusion here.  The point is not to let someone enter data that would violate the referential integrity.  Let me explain with an example:  

1.        User wants to update a primary key record in parent table

2.        Dependent data exists in a child table so the user gets an error while trying to perform step 1

3.        It is necessary to disable the FK constraint in order to update both tables

4.        Enable the FK constraint successfully     Does that make sense?  This is a process we have to do routinely and it has happened in the past that the FK was mistakenly not re-enabled, which allowed "illegal" data to be loaded later.  Thus the need for a script.