Claudio Valderrama C. wrote:

>>-----Original Message-----
>>From: Firebird-Architect@yahoogroups.com
>>[mailto:Firebird-Architect@yahoogroups.com]On Behalf Of Jim Starkey
>>There is no alternative to a tweak to the
>>SQLDA/XSQLDA/YSQLDA, but I'd rather hide this behind a better interface.
>>
>>
>
>Doesn't that IBM- inherited thing have a version field?
>
>

In theory, yes. But I don't think it has ever been initialized or
used. Also, the calls are now defined as passing XSQLDA. If we
generalized them, we'd have to change them to void* or something equally
ambiguous. So, with an eye to the future, we increase the names to 128
characters and add scheme and catalog, taking us to six identifiers at
130 bytes each. That 1K of static structure *per variable*. Could be
done, of course, but only if people have been religiously using the
sqlda version field.

>
>
>
>>A habit we need break is dependence on fixed length strings internally
>>and across our interfaces. I'm not prepared (yet) to argue that the
>>database should only support the concept of "string", both for interface
>>design and internal coding, that's what we should assume.
>>
>>
>
>Suppose my program prepares a statement, specifically a query.
>How does it determine how much memory it should allocate for buffers if the
>only answer from the server is "this is a string", for example?
>
>
>

ResultSet::getString returns a null terminated string. You use it,
assign it to a string class, and copy it before the next "next()". You
don't worry about the length. It's a string.