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.


Cheers,

Ann

Nothing like two double espressos and a good flame war to get the
morning off to a hot start.