>>> This last step would probably require a lot of "knowledge" in fbclient
>>> of all possible character encodings, which I expect would bloat that
>>> dll
>>> a bit more than anyone would like. Or would it?
>>
>> Or just have a character length field in the data you receive and have
>> the server calculate this using the character set information it must
>> already have so on the client side I just get data I can use without
>> jumping through hoops!
>
> But you won't get the data anyway. I don't think that replacing some
> space characters with zero characters in data buffer will somehow help
> you.
> I can't understand why you are so determined to use CHAR when you
> obviously need VARCHAR. They are different datatypes with different
> purposes. You must not bend one to serve for purposes of other.

You are wrong here Dimitry, we want a CHAR with spaces padded, that
is not the problem.

The problem here is how to know that a "space" isn't part of the actual
result, without having to query the system tables for "bytes per character".

Having the N value available for CHAR(N) would solve this problem easily.

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

>> Actually thinking now I'm not even sure I understand exactly what kind
>> of data I'll get back in different situations.
>
> You will get all character data in character set of connection unless
> this character set is NONE.
> If you are connected with character set NONE, you'll get data in
> storage character set.
> In any case field in SQLVAR will indicate this charset.
>
>> Is there a document on all this that I've failed to find?
>
> Yes - Release Notes. Part "sqlsubtype and Attachment Character Set".
>
> SY, SD.