At 01:38 AM 15/08/2006, Martin Knappe wrote:

>--- In firebird-support@yahoogroups.com, "Ivan Prenosil"
><Ivan.Prenosil@...> wrote:
> >
> > > MY understanding of UNICODE_FSS was that it is a 'wide' string
>format,
> > > and that 24bits per character were used, so 3 bytes.
> >
> > No, one character is 1 or 2 or 3 bytes.
>
>Ok, this questiondoesn't really have to do with the subject anymore,
>but if I declare a char or varchar with size x in my database, how
>much memory will be reserved, x bytes, x*3 bytes, ...?

I think the question you are asking is "Does x represent the storage
size in bytes or in characters?"

The answer is that x represents the number of characters. Data
length is calculated as the total number of bytes. The storage size
also depends on whether it is a CHAR or a VARCHAR.

CHAR data is stored as total bytes. Non-null data are padded out to
the maximum physical length. Max. length is 32,767 bytes.

VARCHAR data is stored as total bytes + 2 bytes containing the actual
data length in bytes. The 2 bytes are a 16-bit integer. Thus, max.
length of a varchar is reduced by 2 to 32,765 bytes. There is no
padding of stored varchar data.

Memory isn't "reserved" by a DDL declaration, but the engine uses the
maximum potential byte length when calculating what space it needs to
store a new record version. Memory reserved when local variables and
input and output arguments are used in PSQL modules is calculated by
the same rules; the same when DML statements are prepared. However,
in Fb 1.5 and higher, only CHAR data is padded for transit across the wire.

Please would you make a point to start a new question with a new Subject.

^ heLen