Re: Implementing complicated constraints

From: Holger Baer <holger.baer_at_science-computing.de>
Date: Tue, 05 Oct 2004 12:03:35 +0200
Message-ID: <cjtrhn$g0r$1@news.BelWue.DE>

Noons wrote:
> Holger Baer <holger.baer_at_science-computing.de> wrote in message news:<cjqs9v$pui$1_at_news.BelWue.DE>...
>
>

>>This is an excerpt from the docs on my prehistoric 8.0.6 CD for Windows:

>
>
> Yeah, I believe you. Did a little "digging" myself and found
> out. I'll have to understand why TK is going for FBI rather
> than instead of. Doesn't make sense.
>

I went through chapter 7 of Tom Kyte's book again. It makes perfect sense in the cases he described, because with the trigger you either lock the tables in question, or you end up with constraint violations:

Session A:
insert into view //trigger fires check constraints ok

							Session B:
							insert into view // trigger fires check
									 // constraints ok

Session A:
commit; // trigger does not reevalute constraints

							Session B:
							commit; // now we violated our constraint

I don't have the time at hand to check the proposed solution if it behaves any different, but at least this is something to watch out. And it's the reason why Tom chooses FBI over trigger.

Cheers,

Holger Received on Tue Oct 05 2004 - 05:03:35 CDT