Hello Dmitry,

>> This has nothing to do with fetching data. Having to query the
>> system tables in order to properly process the data as provided
>> by the client side API, does that sound "OK" to you?
>
> 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.

No, the layer should only trim them if the client application requires
that, after all, we -are- using CHAR data here and it should be padded
with spaces, a "space" is a valid character to be processed.

> 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?

For CHAR(10), N = 10, as it's the number of characters that should be
passed on to the caller application. Currently, there appears to be no
way to know what to pass from the API to the caller application, -unless-
you query a system metadata tables and do some calculations. This sounds
like an API defect.

With regards,

Martijn Tonies
Upscene Productions
http://www.upscene.com

Download Database Workbench for Oracle, MS SQL Server, Sybase SQL
Anywhere, MySQL, InterBase, NexusDB and Firebird!

Database questions? Check the forum:
http://www.databasedevelopmentforum.com