Re: compressing primary key indexes

I haven't seen that behaviour at all,
and I have built primary keys on partitioned tables in this way - although not in on that specific version on that specific platform.

Were there any other special circumstances, and is this registered as a bug yet ?

(NB I recall there was a bug at some stage showing this behaviour, but that related to PKs that had been built with the reverse option).

--
Jonathan Lewis
http://www.jlcomp.demon.co.uk

Host to The Co-Operative Oracle Users' FAQ
http://www.jlcomp.demon.co.uk/faq/ind_faq.html

Author of:
Practical Oracle 8i: Building Efficient Databases

Screen saver or Life saver: http://www.ud.com
Use spare CPU to assist in cancer research.

Matthias Gresz wrote in message ...


>In article <999811332.14741.0.nnrp-08.9e984b29_at_news.demon.co.uk>, Jonathan

Lewis


>says...

>>

>>

>>When all else fails, create the index, then

>>add the constraint. There is no inherent

>>reason why you can't do what you want

>>to do - probably some minor detail of

>>irritating syntax.

>>

>>BTW Given that this is a very large table,

>>you may want to create the index 'unusable'

>>then rebuild it partition by partition.

>>

>>--

>

>You sure that this works? With 8.1.6.3.1 on NT I encountered that creating

a PK


>over fields where an index already exists leads to the following behaviour:

>

>When chekcing FK consistency, the  server uses the prebuild index. When

>inserting a new row the prebuild index isn't updated. The result is that

for all


>newly inserted items, oracle refuses to let you insert chield records in a

>chield table.

>

>

>Matthias

>

>