Kjell,

>
>
> 1. What does Milan's code know that fbclient doesn't?

Milan's code knows the relationship between the character set id
and the maximum number of bytes necessary to represent any character
in that representation.

>
> 2. Where does Milan's code get that info from?

Milan's own information. The character to byte ratio is known for
all character sets and the character sets supported by Falcon is
also known. So, for character sets that have variable length
characters, FlameRobin reverse-engineers the buffer ... lets see,
if the buffer is 24 bytes long and the maximum length of a character
in this character set is 4 bytes, then Firebird has created a buffer
for 6 characters and I'll ignore all characters after 6.

>
> 3. Why doesn't fbclient have that info?

Because, as Dmitry S. said, it's a dumb thin client whose major jobs
are to convert between the Firebird API and the network protocol,
establish connections, and communicate.

>
> 4. Can FB be changed so fbclient can get that info in the future, and
> use it to trim the buffer to the right size before passing it to the
> client application?

A better solution, in my mind, would be to pass the number of characters
returned as part of the sqlda structure. Unfortunately, that can't be
done compatibly since it's a C structure and blazingly visible to the
caller. That's why I suggested switching to a type that does natively
return the number of characters returned in a string if you don't want
to see trailing spaces.

None of this has anything to do with "trimming buffers". DSQL operates
on fixed length structures, declared once for a request. It doesn't
return different length packets for different records, even if some
strings are different lengths.

Good luck,

Ann