Subject | Re: [firebird-support] Weird... "keysize too big for index" |
---|---|
Author | Ann W. Harrison |
Post date | 2005-03-15T16:56:20Z |
David Johnson wrote:
length.
is converted to a char, blank-filled, or zero filled for octets. Then
the trailing blanks or zeros are compressed (suffix compression).
A tiny bit of ancient history. In the first two versions of InterBase,
you could declare a key of any length. There was a runtime check to see
that the length of the key could actually be described by a byte. With
prefix and suffix compression, it took two years before the first
customer hit that error, but he screamed loud enough that we heard it
all the way from California. That affected many many more applications,
but definition time errors are easier to handle than runtime.
Regards,
Ann
>Err, varchar(1) is actually three bytes, 1 for the data and 2 for the
> The 25x byte count limit is a function of the engine, though. SQL, per
> se, does not define a limit (although Firebird SQL may enforce one).
>
> VARCHAR(1) is 1 to 2 bytes. One byte for the length, and 1 byte for the
> (optional) data.
length.
>Won't make any difference. Before being used in an index key, a varchar
> Try with CHAR(x) instead of VARCHAR(x).
is converted to a char, blank-filled, or zero filled for octets. Then
the trailing blanks or zeros are compressed (suffix compression).
A tiny bit of ancient history. In the first two versions of InterBase,
you could declare a key of any length. There was a runtime check to see
that the length of the key could actually be described by a byte. With
prefix and suffix compression, it took two years before the first
customer hit that error, but he screamed loud enough that we heard it
all the way from California. That affected many many more applications,
but definition time errors are easier to handle than runtime.
Regards,
Ann