The thing that scares me is that you should never use a column for two
completely
different things. I would suggest

FIELD_DATA_TYPE // English representation like VARCHAR or CLOB
FIELD_INTERNAL_DATA_TYPE // Current numbering system
FIELD_CHARACTER_SET // or whatever you would call it
FIELD_BYTE_SIZE // size in bytes the database needs for internal storage.
FIELD_LENGTH // For characters
FIELD_PRECISION // For number
FIELD_SCALE // For numbers

Daniel Rail wrote:

>Hi,
>
>At February 25, 2005, 12:16, Thomas Miller wrote:
>
>
>
>
>>This is clearly a bug. I think one of the things that the next ODS need
>>to do is store char
>>length and byte length. If it is already doing this, then the engine
>>has a bug in it for not
>>checking both.
>>
>>
>
>It's already storing both values. The problem that Ann is mentioning
>seems to come from the fact that in the system tables,
>RDB$FIELD_LENGTH represents the number of characters and
>RDB$CHARACTER_LENGTH is NULL. Although, when using UNICODE_FSS,
>RDB$CHARACTER_LENGTH represents the number of characters and
>RDB$FIELD_LENGTH represents the number of bytes(i.e.: VARCHAR(90)
>UNICODE_FSS with have RDB$CHARACTER_LENGTH=90 and
>RDB$FIELD_LENGTH=270).
>
>If the handling is related to the system tables, then why not change
>the system tables to reflect the proper behavior of UNICODE_FSS(to be
>done when migrating to a newer ODS only). So, this way there would be
>only one way of handling MBCS characters.
>
>
>
>>If someone has relied on a bug in the engine, their problem.
>>
>>
>
>I totally agree. And, when this change is implemented to have it
>documented in the release notes.
>
>
>