Re: How to bypass referential integrity

Yeah, they're supposed to have fixed the reverse index bug in version 8.1.7. I haven't had a chance to test this problem in 8.1.7 yet. Maybe tomorrow.

Van

"Connor McDonald" <connor_mcdonald_at_yahoo.com> wrote in message news:3B1E6DB5.2EEF_at_yahoo.com...
> 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..."
Received on Wed Jun 06 2001 - 18:27:55 CDT