> The name of the index is always I_CSSAPNR_A, but it there
> a two situations, in which the index seems to behave
> different and in every situation I have given the index
> a different name, it's just for explaining.

So this is an explicitly defined index on the foreign key field of the
main dataset. From this I presume that you do NOT define the foreign
key constraint to the table definition, but are managing the
relationship via triggers. (I presume this because you cannot control
the name of the foreign key index automatically created when you
define a constraint.)

Note: If you are defining the index AND the foreign key constraint -
DONT. Having two identical index definitions can result in confusing
IBs optimiser (at least thats what I've heard).

Since you are defining the index explicitly, why not make it a
compound index by adding the tables primary key after the foreign key
field? Does this make any difference to the phenomenon that you
experience?

> I hope, it's more clear now :-)

Not exactly clear but perhaps I am getting closer. It may help if you
posted more of the actual DDL. Alternatively you may like to try
posting the details to IB_Support, this does not really seem like an
IBO problem and you may get better responses from that list.


Geoff Worboys
Telesis Computing