skoczian wrote:

>
> I've seen the discussion about right padded char(n) fields sent from
> the Firebird server if the field has character set UTF8. But even if
> a char column with fixed length is declared with character set ASCII
> the clients I've used seem to pad it with blanks, if the connection
> character set is UTF8. Is that right? I could understand it for
> columns declared as, say, ISO8859_1, because transliteration to UTF8
> might need more bytes. But that can't happen with an ASCII column,
> so why those blanks?

It's not related to charsets. CHAR values are always space-padded, even
when stored inside the database (although compressed).

> Even with "SELECT TRIM(TRAILING FROM asciifield) FROM mytable" this
> happens.

Of course, because the result is also CHAR.

> It doesn't happen with "SELECT asciifield || '' FROM
> mytable" which might serve as ugly workaround, but again: why?

Because concatenation results in a VARCHAR instead.


Dmitry