Nickolay,

> You did not answer my question. What happens if you ask engine to
> translate XSQLVAR type to SQL_VARYING explicitly for CHAR output
> parameters ? Is it still coming padded ? If no, this can be a nice
> solution for Jaybird users. If yes, then it can be easily fixed
> in database server itself.

I did not try your suggestion yet. However I have posted another test
case to the firebird-devel list that shows that remote protocol is not
involved. Here's the script:

create table test_padding_table(
test_col_unicode char(2) character set unicode_fss,
test_col_octets char(2) character set octets
);

insert into test_padding_table values ('40', '40');

select
'>' || test_col_unicode || '<',
'>' || test_col_octets || '<'
from test_padding_table;

alter table test_padding_table alter column test_col_unicode type
varchar(6);
alter table test_padding_table alter column test_col_octets type
varchar(6);

select
'>' || test_col_unicode || '<',
'>' || test_col_octets || '<'
from test_padding_table;

In both cases selects will produce same data: '>40 <' and '>40<'
respectively.

So I think your suggestion will not help, but I will try it anyway.
Currently my working copy of JayBird is not working, so this might
take some time.

Roman