svanderclock wrote:

> hello,
>
> Ann already answer me but i want to be sure.
> i need to store value from 0 to 255, and need the optimum way to store it
>
> ann advise me to use CHAR CHARSET OCTECTS instead of SMALLINT
>
> 1/ is CHAR(1) will really use only 1 bytes ? or more on the disk ?

CHAR(1) stores between 0 and 2 bytes on disk, depending on what
comes near it. Before storing bytes on disk, Firebird does a
run length compression, adding count bytes. A positive <n> count
byte means that the next <n> bytes appear in the string as they
appear on disk - thus four CHAR(1) fields with values of 1, 2, 3,
& 4 will appear as 4, 1, 2, 3, 4. A negative <n> count means
that the next value appears n * -1 times. Four CHAR(1) field that
all have the value 3 will appear as -4, 3.

> 2/ what the difference between CHAR(1) and VARCHAR(1) ?

Every varchar string is preceded by two binary bytes that contain
the actual length of the string. Four VARCHAR(1) fields containing
the values 1, 2, 3, 4 will appear on disk like this (I think)
12, 0, 1, 1, 0, 1, 2, 0, 1, 3, 0, 1, 4. Four VARCHAR(1) fields
containing the value 3 will appear like this: 12, 0, 1, 3, 0, 1, 32, 0,
1, 3, 0, 1, 3. The order of the high and low bytes is machine
dependent of course, and I think what I've written is big-endian
and not Intel style.

> 3/ If i create the field like this
> CHAR(1) CHARACTER SET OCTETS NOT NULL COLLATE OCTETS
> does it's matter if i set Charset=ISO8859_1 on the
> connection client ? or i absolutelly need to set
> Charset=OCTECTS on the connection clients ? (because i
> will need to do SQL like where Myfield < xxx or > yyy)

I think you just need to qualify the collation of the literals
you pass, but that level of collation work is beyond my experience.
I am sure, though, that you can't use any normal collation or
character set if you intend the values to be handled as binary.
All strings (at least all western European strings) handle the
space character as an insignficant pad, and that will cause
problems.


Cheers,

Ann