Dmitry Yemanov wrote:

> I have some doubts about a "proper processing". For a CHAR value, does
> it mean returning (to the caller application) the string with trailing
> spaces of without? I'd expect a clever intermediate layer to trim them.
> But I suspect this makes this issue independent from the multi-byte
> character sets then, because your N (length in characters) is always 10
> for CHAR(10) regardless of the string stored inside (e.g. 'a') and its
> charset. I mean that XSQLVAR may contain either N = 40 or N = 10, and it
> doesn't change anything for you, as you have to decode the partial
> string anyway. Do I miss anything?

If you ask me, the simplest way to solve this problem is do to the same
thing in the server, which is currently done in applications:

- get the max_char for the charset id
- send that back to the client in XSQLVAR.sclscale field

The client would use this info to do the proper trim of CHAR columns
after conversion from bytes to characters. And it would not require
querying a system table.

I guess it would also not require any intl stuff or anything like that.
I assume it is not problematic to even cache this information upon
attaching to the database for the first time?


--
Milan Babuskov
http://www.flamerobin.org
http://www.guacosoft.com