martinknappe wrote:

> hi
> this may sound like a stupid question but what's the difference
> between using char and varchar fields?

Logically, the difference is that char fields are blank filled to
the full length and the blanks are significant in LIKE comparisons
and appear in concatenations. Varchar fields carry the length of
the specific string entered.

Physically, both varchar and char fields are stored at full length,
blank filled. Varchar fields are preceded by a two byte length.
However, Firebird performs a run length compression on records
before storing them, so the trailing blanks are compressed to
a byte of length and a byte containing a blank for every 127
bytes of padding.

Operationally, this means that char fields are preferable for
strings that are actually fixed length - US social security
numbers, etc., and for very short strings - under 10 characters.
Varchar is preferable for words, names, and other strings that
vary in length (duh!).

>
> 1)
> what happens to a varchar field, once the original string held in it
> is updated - does it mean the whole entry and with it the whole db is
> changed?

When Firebird updates a record, it makes a new copy of the whole record
and a back version. The back version is normally a "delta" - a series
of offset, length, and data bytes that describe the transformation from
the current version to the previous version. Because Firebird uses
versioning for concurrency control, transaction rollback, and snapshot
stability, it never does an update in place. Ever.

> 2)
> if varchar fields have this advantage of being flexible in size, why
> would anyone use char fields? are they faster to access or something?

There's no real difference in storage length - a slight disadvantage
to varchar because of the two extra bytes of length. The advantage
is not having to trim off the trailing blanks.


Regards,


Ann