At 03:53 PM 11/14/2000 +0100, Ivan Prenosil wrote:

>If I remember correctly, older IB versions did not enforce limit on index
>key length
>when creating index, but at runtime. Because index keys are compressed,
>it was possible to store/index longer strings than in current IB versions.

Right. It takes a very unfortunate choice of key values to use the
computed key length, particularly in multi-byte collating sequences.
You have a long memory!

>The problem was that
>- you could get error message even when inserting string that fits to column
> (in current IB you either can index short columns and you are guaranteed
> to not have problems with indexed strings, or you can't index too long
> columns at all)

We had a long and acrimonious discussion when a user reported
(vigorously) that allowing the definition of an index that
could produce an oversized key value was a bug. We should have
bit the bullet then, and increased the key length field from
a byte to a word. Who knew?

>"silent key trimming" should not cause big problems

I continue to thing that silent key trimming is a hack that
will cause more trouble than it saves. In particular,
compound keys in multi-byte collating sequences are just
too small now. Truncating them will create sub-optimal
indexes - unique indexes that are actually much less than
unique, for example.

>But increasing max index key size from 255 to 64K
>seems like proper/long term solution to me.
>Does it have any serious disadvantages ?

It makes each index entry one byte longer. To my knowledge,
it has no other effect. Except, of course, that it's a new
ODS, and could not be read by old versions of Firebird.

Best,

Ann