Thanks, Helen and Claudio!

At 0:22 +1000 7.6.2001,Helen Borrie wrote:

>This rings a bell - I believe it's an IB6 bug that occurs with ALTER
>COLUMN when you alter the length of a varchar - it (wrongly) adds
>two bytes to the new size. Claudio can confirm this when he gets
>round to reading these mails as I think it was he who fixed the bug
>in Firebird....but not before the 0.9.4 version, nor soon enough for
>it to have been in time for inclusion in "certified" InterBase 6...

Yes, that's it. I checked the process of generating that field in question,
and indeed, it was created as varchar(10) and then ALTERed to varchar(20)
later.


At 1:16 -0400 7.6.2001, you, Claudio Valderrama C. wrote:

>Do:
>
>1)
>select f.rdb$field_length, f.rdb$character_length
>from rdb$fields f join rdb$relation_fields rf
>on f.rdb$field_name = rf.rdb$field_source
>and rf.rdb$relation_name = <TABLE>
>and rf.rdb$field_name = <FIELD>;

rdb$field_length = 22
rdb$character_length = 20

>2)
>select max(f.rdb$format)
>from rdb$formats f join rdb$relations r
>on f.rdb$relation_id = r.rdb$relation_id
>and r.rdb$relation_name = <TABLE>;

MAX = 4

Obviously, IBO uses rdb$field_length for limiting the number
of characters that can be input into a field, not rdb$character_length.

Jason,

Is this just an arbitrary choice (that is, could it made to
use rdb$character_length which seems to be correct in all cases)
or is there a reason to use rdb$field_length?

--
Lukas Zeller (luz@...)
-
Synthesis AG, Sustainable Software Concepts
info@..., http://www.synthesis.ch