Ivan,

> It is a FlameRobin bug, because client application has enough
> informations
> to be able to display data correctly.

I fear I don't agree with you, unless you prove me wrong.

Does the XSQLDA/XSQLVAR give all the needed information to fully
describe these details about the columns it returns? Specifically
where should we read in that returned info that the column is a
CHAR(2) even though its physical data buffer is 8 bytes (because of
its character-set being UTF8)?

Or show me where in the returned info, the engine tells me how many
bytes of the 8 bytes of the buffer are filled with the actual string
data?

An UTF8 CHAR(4) containing 'abé' will arrive at the client side as 16
bytes (4 x 4). The caller of the APIs having described the result
columns should be informed that:

a) the buffer is 16 bytes long
b) the data is 4 characters long
c) the data actually uses 5 bytes in the 16 bytes buffer

So the buffer contains 'a', 'b', two bytes representing 'é', and a
space, making 4 characters but 5 bytes. The remaining 11 bytes of the
buffer are 'undefined' but might be set to spaces if that helps with
ascending compatibility.

--
Olivier Mascia
T.I.P. Group S.A.
http://www.tipgroup.com