On 2020-04-02 18:55, Dimitry Sibiryakov wrote:
02.04.2020 17:33, Dimitry Sibiryakov wrote:
Can someone explain how DELAYED_OUT_FORMAT works and its purpose
in general?
To be precise, here is a piece of call log from my provider:
0037ce20 ODBCAttachment::prepare("select Point_ID, Max_PDOP from
dbase_03", 3, 47)
0037cfb8 ODBCStatement::getOutputMetadata()
Returning metadata 00266e14
0037cfb8 ODBCStatement::getOutputMetadata()
Returning metadata 002670b4
0037cfb8 ODBCStatement::getInputMetadata()
Returning metadata 00267354
0037cfb8 ODBCStatement::openCursor(0)
Input metadata (0 fields)
Use external metadata 00000001
I cannot understand why IStatement::openCursor() got
DELAYED_OUT_FORMAT as outMetadata after it was asked for output
metadata twice and returned them.
Delayed metadata arrives only with first fetch call. That's the first
moment when XSQLDA (i.e. metadata) is passed to ISC API. I.e. if
provider is expected to support ISC API it should be ready to check for
DELAYED_OUT_FORMAT (engine does the following):
if (outMetadata == DELAYED_OUT_FORMAT)
{
needDelayedFormat = true;
outMetadata = NULL;
}
and move any outMetadata-related activity from openCursor to fetch.
A.
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
