"Olivier Mascia" wrote:

> By the way, I don't think the user of the API has use for the buffer
> length. The buffer has been allocated by the API

When you prepare the statement, API will return (among other informations)
desired length of buffer. It is task of the application to allocate the buffer.
When you then fetch the data, that length is again used by the API
to verify whether the data fit.
(Because you can allocate smaller buffer, provided you set its length
in sqlvar structure appropriately. You can even change datatype
and let FB do conversion for you, e.g. fetch integer data into varchar
buffer, which then must be longer that 4 bytes.)


I am not against any useful improvement, just wanted to point out
that xsqlvar.sqllen member is IMO not good candidate for such change.


My main point was that it is not necessary for programmers to wait
one year or more until FB allows retrieving actual data length e.g. like

xsqlda^.sqlvar[col].data_length

because you can get the same result today by calling very simple
(~10 lines) function like

GetDataLength( xsqlda^.sqlvar[col] )

or you can let FB return that length using VARCHAR format
by single line of code which chages

xsqlda^.sqlvar[col].sqltype := ...

Ivan