|
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. David B. Wagoner Database Administrator Arsenal Digital Solutions Worldwide Inc. 4815 Emperor
Blvd., Suite 110 Durham, NC 27703 Tel. (919)
941-4645 Fax (919)
474-0735 Email mailto:[EMAIL PROTECTED] Web http://www.arsenaldigital.com/
*** NOTICE *** This e-mail
message is confidential, intended only for the named recipient(s) above and may
contain information that is privileged, work product or exempt from disclosure
under applicable law. If you have
received this message in error, or are not the named recipient(s), please
immediately notify the sender at (919) 941-4645 and delete this e-mail message
from your computer. Thank you. -----Original
Message----- How could this be user
proof? You are essentially disabling the constraint that WILL enforce data
integrity, then letting the user input whatever rubbish he wants to, and are
then going to try and enable the constraint afterwards? Not a good approach.. How
can you ensure that the user hasn't put a duplicate value in (unique
constraint) or something else that might break the constraint rule? The only
way you are going to know is when you try and re-enable the constraint it will
fail.. I struggle to see why you
would want to do this - do you have any more info? -----Original Message----- Listers, Does anyone have a script that will do the following: 1. Accept user input for old
data value 2. Accept user input for new
data value 3. Disable table constraint 4. Update record with new data
value 5. Enable constraint A script like this would help ensure that constraints
are not left "off" after updates, allowing "illegal" data
into the tables. Good user-proof
script I would think. TIA, david David B. Wagoner Database Administrator Arsenal Digital Solutions Worldwide Inc. 4815 Emperor Blvd., Suite 110 Durham, NC 27703 Tel. (919) 941-4645 Fax (919) 474-0735 Email mailto:[EMAIL PROTECTED] Web http://www.arsenaldigital.com/
***
NOTICE *** This e-mail message is confidential, intended only for the
named recipient(s) above and may contain information that is privileged, work
product or exempt from disclosure under applicable law. If you have received this message in
error, or are not the named recipient(s), please immediately notify the sender
at (919) 941-4645 and delete this e-mail message from your computer. Thank you. |
- RE: Script to Disable Constraint, Change Value, the... Hallas John
- Re: Script to Disable Constraint, Change Value... David Wagoner
- Re: Script to Disable Constraint, Change Value... Igor Neyman
- RE: Script to Disable Constraint, Change Value... tday6
- Re: Script to Disable Constraint, Change Value... Stephane Faroult
- RE: Script to Disable Constraint, Change Value... Cale, Rick T (Richard)
- RE: Script to Disable Constraint, Change Value... David Wagoner
- RE: Script to Disable Constraint, Change Value... Cale, Rick T (Richard)
- RE: Script to Disable Constraint, Change Value... David Wagoner
- RE: Script to Disable Constraint, Change Value... Khedr, Waleed
