Re: How to bypass referential integrity

Van Messner wrote:
>
> Here's the setup.
> Table A has an primary key AKEY
> Table B has a primary key BKEY
> Table INT is an intersection between A and B. INT has a column called AKEY
> which is foreign keyed back to the same column in A. INT has a column
> called BKEY which is foreign keyed back to the same column in B. In table
> INT the primary key is the columns AKEY and BKEY. There are regular b-tree
> indexes on AKEY and on BKEY in INT. A standard setup.
>
> If you put data into A, B and INT, then deleting data from A or B when child
> rows exist in INT causes an Oracle error.
>
> BUT now compress the index on AKEY in INT and compress the index on BKEY in
> INT. You can then delete rows in either A or B or both where child rows
> exist in INT, leaving orphan rows behind in INT and Oracle gives no error
> message.
>
> Van

Seems to me like no-one read your post fully, and responded with "or, just make them deferrable or disable them"...

There's a number of bugs with compression that seem to be getting sorted out as each new version/patch comes out...For example, on 8.1.5/6 (I think) after you analyze a compressed index, the "distinct keys" stat goes artificially high...

Cheers
Connor

-- 
==============================
Connor McDonald

http://www.oracledba.co.uk

"Some days you're the pigeon, some days you're the statue..."