Thanks for the reply Dmitry.

The actual FB version is v2.1.1

>> Can anyone explain why the combining of two client indexes by FB in
>> the first query i.e. C INDEX (IDXCLNTFULLNAME, FK1_CLIENT)) should
>> cause such a performance hit please?

> I believe it's not about indices, but about SORT vs ORDER plans

Ok, but is there not a well-known problem that crops up when FB tries
to combine multiple indexes on a single table through bitmapping the
matching index entries (or some similar technique)?

And is this not the culprit of certain types of baffling slow queries
that have to have the SQL modified with +0 or || '' to STOP the
optimiser combining the default indexes that it would have done so (as
in the 2nd example)?

Tom