Hi Dave,

> Thanks for your help. Have I been worrying my poor old head about
> wasting space for all this time? Why not have a varchar(255) if it
> really takes no space in the database when null?
> Yes I expect to use memo components to put such comments in.
> I suppose I could do some experiment to test the fact that null
> columns occupy no space but I have not seen that in the Interbase
> manuals anywhere...perhaps I should know it anyway. I have always
> been confused about varchar(20) versus char(20).
> Any confirmation would be welcome.
> Dave

fyi: whenever a record is actually written to the gdb, FB/IB *always*
performs a run length encoding on the entire record. Iirc, even 64bit ints
get RLE'd when they are = 0. So from this pov, it makes absolutely no
difference whether your field is varchar(1), varchar(100) or varchar(1000).
Same goes for char(1) vs. char(1000).

BUT: it does make a *big* difference concerning network traffic.

(i asked the same question some months ago on IB-Support, and Ann H's
comment was "Well, somebody had to ask..." ;-) From her explanation i
took the following conclusion:

- GDB space is hardly at all affected by the size you declare (->RLE)
- Char vs. Varchar makes a difference of 2 length bytes, that's it.
- for the network: across the wire always goes the decoded field in
full length (may it all be blanks, no difference) + the length info

So a Select that returns 1000 all-blanks char fields will give you
1000 * (20+2) for varchar(20), but 1000 * (1000+2) for varchar(1000) !!

-> my biggest wish for FB2: run length encoding for the network
transmission! <bg>

fwiw - regards,
fingerman