> Ann W. Harrison wrote:
>
> much too quickly...
>>
>>
>>... but it would be a protocol change and would not work
>> with existing clients. It could be introduced so the client and
>> server determine the capabilities of each and a new server uses the
>> old protocol talking to new clients to preserve upward compatibility
>
> should have been
>
> old protocol talking to *old* clients ...
>
>> between applications and the Firebird server. But a new client that
>> depends on the new capabilities would not connect to an old server.
>> Frankly, I don't think this problem is worth that effort and the
>> accompanying incompatibility.
>>
>
> Since this is a problem specific to CHAR fields used with variable
> length character sets (which weren't much of an issue in 1986 when
> the SQLDA was designed) perhaps the field
>
> ISC_SHORT sqlsubtype; /* datatype subtype - currently BLOBs only */
>
> could be used to pass the length in characters if the data being
> sent is CHAR. That field is (I hope) set to zero currently for
> non-blob fields. There are no fields or values that are both CHAR
> and BLOB. If the client gets a 0 for sqlsubtype, then its talking
> to an old server and has to do the computation itself. If it gets
> a non-zero value for a CHAR field, then that value is the N in
> CHAR(N). In the bad old days, we sort of assumed that application
> writers knew the size of their CHAR fields.

I guess that was when each and every application used the API and
you didn't have multi-byte-charactersets ;-)

The components that use the API currently have no way of knowing
of the spaces (padded to CHAR-data) are spaces that should be
part of the data, or are simply padding to fill up the buffer.

So that's quite different from the bad old days, isn't it?

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