Dimitry,

>> But the application's work would be a lot easier if N (or
>> "bytesactuallyused") were contained in the (X)SQLVAR struct.
>
> And good news are: "bytesactuallyused" is contained. For VARCHAR.

We don't want VARCHAR, we want CHAR.

Having to query the system tables in order to retrieve data from the
API is rather strange, it's a defect in the API, no matter what direction
you look at it.

>> Yes, if the struct docs says that the buffer will be padded with spaces
>> up to N codepoints and \0 beyond that. But that would also require that
>> \0 can't occur in the actual data value. I suppose that is and should
>> still be allowed, so i that case the change in padding would not help.
>
> \0 is allowed in cahracter set OCTETS only. All other character sets,
> including NONE, prohibit it.
>
>> But note that noone has asked for that change in padding. What we've
>> been asking for is N or "bytesactuallyused". And that *would* help.
>
> And this is exactly the reason for VARCHAR existence - to have actual
> length on the string.

Why do you keep insisting on VARCHAR?

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