of declare/fetch and strange HY010 errors - Mailing list pgsql-odbc

Greetings all,

A long time ago, Hiroshi Inoue asked an interesting question about the
declare/fetch option and its default setting of FALSE:
        http://archives.postgresql.org/pgsql-interfaces/1999-01/msg00189.php
To which Byron Nikolaidis replied in
        http://archives.postgresql.org/pgsql-interfaces/1999-01/msg00194.php
why it was left at false.

Well, I'm pumping today datasets from 7.3.3 using the 7.03.0100 ODBC driver
which contain empty, near empty and really large tables, and I'm seeing very
strange things.

If I don't do anything, I don't have the declare/fetch mechanism in place.
I issue all my requests by following the allocate statement, bind columns,
prepare, execute and then SQLFetch() while SQLFetch doesn't return
SQL_NO_DATA. Things run fine for empty and small tables, and even for
largish tables (until I reach memory implementation limits).

If I set the connection attribute SQL_ATTR_ODBC_CURSORS to
SQL_CUR_USE_IF_NEEDED, and then set the statement's SQL_ATTR_CURSOR_TYPE to
SQL_CURSOR_STATIC, then nothing really different happens. No declare/fetch
either, terrible memory consumption, etc. Just for kicks, I also tried
SQL_CURSOR_FORWARD_ONLY, but no change.

Regardless of what I do with the attributes, if I tick the Declare/Fetch
checkbox in the ODBC data source settings, I get the declare/fetch
behaviour. However, that means that I'm at the mercy of a change of options
in the control panel. Besides, by depending on this (as Byron pointed out in
1999 if that statement is not obsolete today), I'm wedding myself to
SQL_ATTR_CURSOR_SCROLLABLE == SQL_NONSCROLLABLE (it's not really a problem
today, but I don't like to close doors).
But the real problem is the following: for some select queries, I'm not sure
I understood when exactly, I don't get what I expect to: the first SQLFetch
will return an SQL_ERROR + HY010 instead of SQL_NO_DATA or SQL_SUCCESS.
This seems to happen on both empty and non-empty result sets, and it seems
that in both cases the engine successfully performed the query and returned
the results.

My questions:
    1. is the HY010 error code for the first SQLFetch() on empty SELECTs,
only in the declare/fetch case, a normal and expected behaviour?

    What puzzles me is that some requests ON THE SAME TABLE return
SQL_ERROR+HY010, some return SQL_NO_DATA. Though, in both cases, the same
code path is used, and indeed the HSTMT follows the exact same life cycle!
I don't understand what happens, the only difference I see is that apparently
the failing requests can't follow a straight sequential plan, while the
succeeding ones apparently can (being vanilla SELECTs with no funky clauses
behind). I don't see how that can possibly make a difference, as according
to the communication log, the back-end is perfectly happy with whatever the
ODBC driver throws at it (see appendices A and B).

    2. is there a way to avoid ticking the declare/fetch box, yet
getting its effects? Specifically, I can't assume I know what kind of
database engine I'll be coupled with until I identify the database back-end
associated with the ODBC data source I'm using. So obviously, it's a bit
difficult to provide psqlODBC-specific connection string options. Is there a
way to turn on the declare/fetch behaviour on an active connection?

    3. is there a way to request the declare/fetch behaviour on a
per-cursor way, without hitting back the problem in point 1? It seemed to me
that some of the statement attributes may make sense as declare/fetch
discriminators (especially for a non-scrollable cursor or a forward-scroll
only cursor), but I guess this isn't implemented today.

Thanks in advance.

    -- Cyrille

Appendix A: extracts from a DbgView log file (slightly edited and commented):
------------------------------------------

00000009  15:34:20  [1436] Detected PostgreSQL ODBC driver
00000010  15:34:20  [1436] SQLAllocHandle(STMT) -->012E2048, 0
00000011  15:34:20  [1436] SQLSetStmtAttr(012E2048,STATIC)-->0
00000012  15:34:20  [1436] SQLPrepare(012E2048)-->0 [SELECT lkb.xge FROM lkb
WHERE ((lkb.dgb = 'ek') AND (lkb.fgb = 'ik') AND (lkb.hgb = 'mk_kh')) ORDER
BY lkb.dgb,lkb.fgb,lkb.hgb]
00000013  15:34:20  [1436] bound columns
00000014  15:34:20  [1436] SQLExecute(012E2048)-->0
00000015  15:34:20  [1436] skipping getResultSize, returning 0
00000016  15:34:20  [1436] SQLFetch(012E2048)-->-1
00000017  15:34:20  [1436] SQL Error in Fetch/1: HY010 [Microsoft][ODBC
Driver Manager] Function sequence error
00000018  15:34:20  [1436] bad Fetch/1 was for sql=SELECT lkb.xge FROM lkb
WHERE ((lkb.dgb = 'ek') AND (lkb.fgb = 'ik') AND (lkb.hgb = 'mk_kh')) ORDER
BY lkb.dgb,lkb.fgb,lkb.hgb
00000019  15:34:20  [1436] closeCursor/SQLFreeHandle(012E2048)-->0
00000020  15:34:20  [1436] SQLFreeHandle(012E2048)-->0
00000021  15:34:20  [1436] SQLAllocHandle(STMT) -->012E2048, 0
00000022  15:34:20  [1436] SQLSetStmtAttr(012E2048,STATIC)-->0
00000023  15:34:20  [1436] SQLPrepare(012E2048)-->0 [SELECT lkb.xge FROM lkb
WHERE ((lkb.dgb = 'ek') AND (lkb.fgb = 'ik') AND (lkb.hgb = 'kh_rij')) ORDER
BY lkb.dgb,lkb.fgb,lkb.hgb]
00000024  15:34:20  [1436] bound columns
00000025  15:34:20  [1436] SQLExecute(012E2048)-->0
00000026  15:34:20  [1436] skipping getResultSize, returning 0
00000027  15:34:20  [1436] SQLFetch(012E2048)-->-1
00000028  15:34:20  [1436] SQL Error in Fetch/1: HY010 [Microsoft][ODBC
Driver Manager] Function sequence error
00000029  15:34:20  [1436] bad Fetch/1 was for sql=SELECT lkb.xge FROM lkb
WHERE ((lkb.dgb = 'ek') AND (lkb.fgb = 'ik') AND (lkb.hgb = 'kh_rij')) ORDER
BY lkb.dgb,lkb.fgb,lkb.hgb
00000030  15:34:20  [1436] closeCursor/SQLFreeHandle(012E2048)-->0
00000031  15:34:20  [1436] SQLFreeHandle(012E2048)-->0

    *** one can see the problem I have, above ***

00000041  15:34:23  [1436] SQLAllocHandle(STMT) -->012E37B0, 0
00000042  15:34:23  [1436] SQLSetStmtAttr(012E37B0,STATIC)-->0
00000043  15:34:23  [1436] SQLPrepare(012E37B0)-->0 [SELECT
vac.yzb,vac.aac,vac.cac,vac.eac FROM vac ORDER BY vac.aac]
00000044  15:34:23  [1436] bound columns
00000045  15:34:23  [1436] SQLExecute(012E37B0)-->0
00000046  15:34:23  [1436] skipping getResultSize, returning 0
00000047  15:34:23  [1436] SQLFetch(012E37B0)-->-1
00000048  15:34:23  [1436] SQL Error in Fetch/1: HY010 [Microsoft][ODBC
Driver Manager] Function sequence error
00000049  15:34:23  [1436] bad Fetch/1 was for sql=SELECT
vac.yzb,vac.aac,vac.cac,vac.eac FROM vac ORDER BY vac.aac
00000050  15:34:23  [1436] SQLAllocHandle(STMT) -->012E4AE0, 0
00000051  15:34:23  [1436] SQLSetStmtAttr(012E4AE0,STATIC)-->0
00000052  15:34:23  [1436] SQLPrepare(012E4AE0)-->0 [SELECT qob.xge FROM qob
WHERE (qob.azc = 'to') ORDER BY qob.azc]
00000053  15:34:23  [1436] bound columns
00000054  15:34:23  [1436] SQLExecute(012E4AE0)-->0
00000055  15:34:23  [1436] skipping getResultSize, returning 0
00000056  15:34:23  [1436] SQLFetch(012E4AE0)-->-1
00000057  15:34:23  [1436] SQL Error in Fetch/1: HY010 [Microsoft][ODBC
Driver Manager] Function sequence error
00000058  15:34:23  [1436] bad Fetch/1 was for sql=SELECT qob.xge FROM qob
WHERE (qob.azc = 'to') ORDER BY qob.azc

    *** it's possible to see that it happens regardless of whether I
have a WHERE clause or not.

00000059  15:34:23  [1436] begin saveNoTimeTable ds
00000060  15:34:23  [1436] SQLAllocHandle(STMT) -->012E5F30, 0
00000061  15:34:23  [1436] SQLSetStmtAttr(012E5F30,STATIC)-->0
00000062  15:34:23  [1436] SQLPrepare(012E5F30)-->0 [SELECT
ds.tre,ds.iic,ds.rq,ds.yzb,ds.vq,ds.xq,ds.zq,ds.br,ds.dr,ds.fr,ds.hr,ds.jr
FROM ds]
00000063  15:34:23  [1436] bound columns
00000064  15:34:23  [1436] about to execute NoTime SELECT
ds.tre,ds.iic,ds.rq,ds.yzb,ds.vq,ds.xq,ds.zq,ds.br,ds.dr,ds.fr,ds.hr,ds.jr
FROM ds
00000065  15:34:23  [1436] SQLExecute(012E5F30)-->0
00000066  15:34:23  [1436] getting results (1)
00000067  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000068  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000069  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000070  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000071  15:34:23  [1436] SQLFetch(012E5F30)-->100
00000072  15:34:23  [1436] absorbing results (1), 4 rows
00000073  15:34:23  [1436] storing results
00000074  15:34:23  [1436] sending progress feedback
00000075  15:34:23  [1436] saveTableFooter ds
00000076  15:34:23  [1436] closeCursor/SQLFreeHandle(012E5F30)-->0
00000077  15:34:23  [1436] SQLFreeHandle(012E5F30)-->0

    *** This was the first successful table. It contained a few records.

00000078  15:34:23  [1436] begin saveTimeTable kxs
00000079  15:34:23  [1436] now saving table kxs with time
00000080  15:34:23  [1436] SQLAllocHandle(STMT) -->012E6338, 0
00000081  15:34:23  [1436] SQLSetStmtAttr(012E6338,STATIC)-->0
00000082  15:34:23  [1436] SQLPrepare(012E6338)-->0 [SELECT

kxs.hv,kxs.jv,kxs.lv,kxs.nv,kxs.pv,kxs.rv,kxs.tv,kxs.vv,kxs.xv,kxs.zv,kxs.bw,kxs.molsw,kxs.molvw,kxs.hw,kxs.jw,kxs.uw3sw,kxs.uw3vw,kxs.uw2sw,kxs.uw2vw,kxs.zw2dh,kxs.zw3dh,kxs.dx0,kxs.dx1,kxs.dxt,kxs.hx0,kxs.jx,sf
00000083  15:34:23  [1436] bound columns
00000084  15:34:23  [1436] about to execute Time SELECT

kxs.hv,kxs.jv,kxs.lv,kxs.nv,kxs.pv,kxs.rv,kxs.tv,kxs.vv,kxs.xv,kxs.zv,kxs.bw,kxs.molsw,kxs.molvw,kxs.hw,kxs.jw,kxs.uw3sw,kxs.uw3vw,kxs.uw2sw,kxs.uw2vw,kxs.zw2dh,kxs.zw3dh,kxs.dx0,kxs.dx1,kxs.dxt,kxs.hx0,kxs.jx,kx
00000085  15:34:23  [1436] SQLExecute(012E6338)-->0
00000086  15:34:23  [1436] getting results (1)
00000087  15:34:23  [1436] SQLFetch(012E6338)-->0
00000088  15:34:23  [1436] SQLFetch(012E6338)-->0
00000089  15:34:23  [1436] SQLFetch(012E6338)-->0
00000090  15:34:23  [1436] SQLFetch(012E6338)-->0
00000091  15:34:23  [1436] SQLFetch(012E6338)-->0
00000092  15:34:23  [1436] SQLFetch(012E6338)-->0
00000093  15:34:23  [1436] SQLFetch(012E6338)-->0
00000094  15:34:23  [1436] SQLFetch(012E6338)-->0
00000095  15:34:23  [1436] SQLFetch(012E6338)-->0
00000096  15:34:23  [1436] SQLFetch(012E6338)-->0
00000097  15:34:23  [1436] SQLFetch(012E6338)-->0
00000098  15:34:23  [1436] SQLFetch(012E6338)-->0
00000099  15:34:23  [1436] SQLFetch(012E6338)-->0
00000100  15:34:23  [1436] SQLFetch(012E6338)-->0
00000101  15:34:23  [1436] SQLFetch(012E6338)-->0
00000102  15:34:23  [1436] SQLFetch(012E6338)-->100
00000103  15:34:23  [1436] absorbing results (1), 15 rows
00000104  15:34:23  [1436] storing results
00000105  15:34:23  [1436] sending progress feedback
00000106  15:34:23  [1436] saveTableFooter kxs
00000107  15:34:23  [1436] closeCursor/SQLFreeHandle(012E6338)-->0
00000108  15:34:23  [1436] SQLFreeHandle(012E6338)-->0
00000109  15:34:23  [1436] begin saveNoTimeTable jab
00000110  15:34:23  [1436] SQLAllocHandle(STMT) -->012E3498, 0
00000111  15:34:23  [1436] SQLSetStmtAttr(012E3498,STATIC)-->0
00000112  15:34:23  [1436] SQLPrepare(012E3498)-->0 [SELECT
jab.rbd,jab.rz,jab.tz FROM jab]
00000113  15:34:23  [1436] bound columns
00000114  15:34:23  [1436] about to execute NoTime SELECT
jab.rbd,jab.rz,jab.tz FROM jab
00000115  15:34:23  [1436] SQLExecute(012E3498)-->0
00000116  15:34:23  [1436] getting results (1)
00000117  15:34:23  [1436] SQLFetch(012E3498)-->100
00000118  15:34:23  [1436] absorbing results (1), 0 rows
00000119  15:34:23  [1436] storing results
00000120  15:34:23  [1436] sending progress feedback
00000121  15:34:23  [1436] saveTableFooter jab
00000122  15:34:23  [1436] closeCursor/SQLFreeHandle(012E3498)-->0
00000123  15:34:23  [1436] SQLFreeHandle(012E3498)-->0

    *** This table was successful too, and yet it was empty.

    *** And now it becomes very strange:

00000203  15:34:23  [1436] begin saveNoTimeTable lkb
00000204  15:34:23  [1436] SQLAllocHandle(STMT) -->012E5F30, 0
00000205  15:34:23  [1436] SQLSetStmtAttr(012E5F30,STATIC)-->0
00000206  15:34:23  [1436] SQLPrepare(012E5F30)-->0 [SELECT
lkb.dgb,lkb.fgb,lkb.hgb,lkb.xge FROM lkb]
00000207  15:34:23  [1436] bound columns
00000208  15:34:23  [1436] about to execute NoTime SELECT
lkb.dgb,lkb.fgb,lkb.hgb,lkb.xge FROM lkb
00000209  15:34:23  [1436] SQLExecute(012E5F30)-->0
00000210  15:34:23  [1436] getting results (1)
00000211  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000212  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000213  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000214  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000215  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000216  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000217  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000218  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000219  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000220  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000221  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000222  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000223  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000224  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000225  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000226  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000227  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000228  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000229  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000230  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000231  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000232  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000233  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000234  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000235  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000236  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000237  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000238  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000239  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000240  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000241  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000242  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000243  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000244  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000245  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000246  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000247  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000248  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000249  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000250  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000251  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000252  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000253  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000254  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000255  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000256  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000257  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000258  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000259  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000260  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000261  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000262  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000263  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000264  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000265  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000266  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000267  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000268  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000269  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000270  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000271  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000272  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000273  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000274  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000275  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000276  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000277  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000278  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000279  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000280  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000281  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000282  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000283  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000284  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000285  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000286  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000287  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000288  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000289  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000290  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000291  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000292  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000293  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000294  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000295  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000296  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000297  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000298  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000299  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000300  15:34:23  [1436] SQLFetch(012E5F30)-->0
00000301  15:34:23  [1436] SQLFetch(012E5F30)-->100
00000302  15:34:23  [1436] absorbing results (1), 90 rows
00000303  15:34:23  [1436] storing results
00000304  15:34:23  [1436] sending progress feedback
00000305  15:34:23  [1436] saveTableFooter lkb
00000306  15:34:23  [1436] closeCursor/SQLFreeHandle(012E5F30)-->0
00000307  15:34:23  [1436] SQLFreeHandle(012E5F30)-->0

    *** Yes, lkb is the first table attempted above. Yes, the one which
had the first an HY010 on it. Yes, this time the request succeeded.

    *** same thing happens for the vac table:

00000438  15:34:24  [1436] begin saveNoTimeTable vac
00000439  15:34:24  [1436] SQLAllocHandle(STMT) -->012E5F30, 0
00000440  15:34:24  [1436] SQLSetStmtAttr(012E5F30,STATIC)-->0
00000441  15:34:24  [1436] SQLPrepare(012E5F30)-->0 [SELECT
vac.yzb,vac.aac,vac.cac,vac.eac FROM vac]
00000442  15:34:24  [1436] bound columns
00000443  15:34:24  [1436] about to execute NoTime SELECT
vac.yzb,vac.aac,vac.cac,vac.eac FROM vac
00000444  15:34:24  [1436] SQLExecute(012E5F30)-->0
00000445  15:34:24  [1436] getting results (1)
00000446  15:34:24  [1436] SQLFetch(012E5F30)-->0
00000447  15:34:24  [1436] SQLFetch(012E5F30)-->100
00000448  15:34:24  [1436] absorbing results (1), 1 rows
00000449  15:34:24  [1436] storing results
00000450  15:34:24  [1436] sending progress feedback
00000451  15:34:24  [1436] saveTableFooter vac
00000452  15:34:24  [1436] closeCursor/SQLFreeHandle(012E5F30)-->0
00000453  15:34:24  [1436] SQLFreeHandle(012E5F30)-->0

Appendix B
----------
Extracts from the psqlodbc_1436.log file (using the same censorship filter):

conn = 22495288, PGAPI_Connect(DSN='LemoineGDB', UID='LemoineUser',
PWD='xxxxx')
Global Options: Version='07.03.0100', fetch=100, socket=4096,
unknown_sizes=0, max_varchar_size=254, max_longvarchar_size=8190
                disable_optimizer=0, ksqo=1, unique_index=1,
use_declarefetch=1
                text_as_longvarchar=1, unknowns_as_longvarchar=0,
bools_as_char=1 NAMEDATALEN=64
                extra_systable_prefixes='dd_;', conn_settings=''
conn_encoding='OTHER'
conn=22495288, query=' '
conn=22495288, query='BEGIN'
conn=22495288, query='declare SQL_CUR01572900 cursor for select version()'
conn=22495288, query='fetch 100 in SQL_CUR01572900'
    [ fetched 1 rows ]
    [ PostgreSQL version string = 'PostgreSQL 7.3.3 on i686-pc-cygwin,
compiled by GCC gcc (GCC) 3.2 20020927 (prerelease)' ]
    [ PostgreSQL version number = '7.3' ]
conn=22495288, query='close SQL_CUR01572900'
conn=22495288, query='COMMIT'
conn=22495288, query='set DateStyle to 'ISO''
conn=22495288, query='declare SQL_CUR01572900 cursor for select oid from
pg_type where typname='lo''
conn=22495288, query='fetch 100 in SQL_CUR01572900'
    [ fetched 0 rows ]
conn=22495288, query='close SQL_CUR01572900'
conn=22495288, query='COMMIT'
conn=22495288, query='select pg_client_encoding()'
    [ fetched 1 rows ]
    [ Client encoding = 'UNICODE' (gse = 6) ]
conn=22495288, query='declare SQL_CUR0157A0C0 cursor for select relname,
nspname, relkind from pg_catalog.pg_class, pg_catalog.pg_namespace where
relkind in ('r', 'v') and relname !~ '^pg_|^dd_' and pg_namespace.oid =
relnamespace order by nspname, relname'
conn=22495288, query='fetch 100 in SQL_CUR0157A0C0'
    [ fetched 43 rows ]
conn=22495288, query='close SQL_CUR0157A0C0'
conn=22495288, query='select current_schema()'
    [ fetched 1 rows ]
conn=22495288, query='declare SQL_CUR0157A0C0 cursor for select u.nspname,
c.relname, a.attname, a.atttypid, t.typname, a.attnum, a.attlen,
a.atttypmod, a.attnotnull, c.relhasrules, c.relkind from
pg_catalog.pg_namespace u, pg_catalog.pg_class c, pg_catalog.pg_attribute a,
pg_catalog.pg_type t where u.oid = c.relnamespace and (not a.attisdropped)
and c.oid= a.attrelid and a.atttypid = t.oid and (a.attnum > 0) and
c.relname like 'lkb' and u.nspname like 'public' order by u.nspname,
c.relname, attnum'
conn=22495288, query='fetch 100 in SQL_CUR0157A0C0'
    [ fetched 4 rows ]
PGAPI_Columns: table='lkb',field_name='dgb',type=1043,name='varchar'
PGAPI_Columns: table='lkb',field_name='fgb',type=1043,name='varchar'
PGAPI_Columns: table='lkb',field_name='hgb',type=1043,name='varchar'
PGAPI_Columns: table='lkb',field_name='xge',type=1043,name='varchar'
conn=22495288, query='close SQL_CUR0157A0C0'
conn=22495288, query='declare SQL_CUR01572900 cursor for SELECT lkb.xge FROM
lkb WHERE ((lkb.dgb = 'ek') AND (lkb.fgb = 'ik') AND (lkb.hgb = 'mk_kh'))
ORDER BY lkb.dgb,lkb.fgb,lkb.hgb'
conn=22495288, query='fetch 100 in SQL_CUR01572900'
    [ fetched 1 rows ]
conn=22495288, query='COMMIT'
conn=22495288, query='declare SQL_CUR01572900 cursor for SELECT lkb.xge FROM
lkb WHERE ((lkb.dgb = 'ek') AND (lkb.fgb = 'ik') AND (lkb.hgb = 'kh_rij'))
ORDER BY lkb.dgb,lkb.fgb,lkb.hgb'
conn=22495288, query='fetch 100 in SQL_CUR01572900'
    [ fetched 0 rows ]
conn=22495288, query='COMMIT'
conn=22495288, query='declare SQL_CUR01572900 cursor for SELECT lkb.xge FROM
lkb WHERE ((lkb.dgb = 'ek') AND (lkb.fgb = 'ik') AND (lkb.hgb = 'mk_nk'))
ORDER BY lkb.dgb,lkb.fgb,lkb.hgb'
conn=22495288, query='fetch 100 in SQL_CUR01572900'
    [ fetched 1 rows ]
conn=22495288, query='COMMIT'

    *** I don't see a need to continue; it seems that as far as the back-end
is concerned, there is no problem issuing and fetching the results for the
lkb table (what we see here is the first few queries which returned HY010's)


Appendix C:
-----------
The first query as seen from the debug log (it's another run, but with the
same results):

[1796][[SQLAllocHandle]][1796]PGAPI_AllocStmt: entering...
[1796]**** PGAPI_AllocStmt: hdbc = 22495288, stmt = 22489384
[1796]CC_add_statement: self=22495288, stmt=22489384
[1796][[SQLGetStmtAttr]] Handle=22489384 10010
[1796]PGAPI_GetStmtAttr Handle=22489384 10010
[1796][[SQLGetStmtAttr]] Handle=22489384 10011
[1796]PGAPI_GetStmtAttr Handle=22489384 10011
[1796][[SQLGetStmtAttr]] Handle=22489384 10012
[1796]PGAPI_GetStmtAttr Handle=22489384 10012
[1796][[SQLGetStmtAttr]] Handle=22489384 10013
[1796]PGAPI_GetStmtAttr Handle=22489384 10013
[1796][[SQLSetStmtAttr]] Handle=22489384 6,0
[1796]PGAPI_SetStmtAttr Handle=22489384 6,0
[1796]PGAPI_SetStmtOption: entering...
[1796]SetStmtOption(): SQL_CURSOR_TYPE = 0 [1796]-> 0
[1796][SQLPrepare][1796]PGAPI_Prepare: entering...
[1796]**** PGAPI_Prepare: STMT_ALLOCATED, copy
[1796][SQLBindCol][1796]PGAPI_BindCol: entering...
[1796]**** PGAPI_BindCol: stmt = 22489384, icol = 1
[1796]**** : fCType=1 rgb=12a5278 valusMax=256 pcb=12a5060
[1796]extend_column_bindings: entering ... self=22489464,
bindings_allocated=0, num_columns=1
[1796]exit extend_column_bindings
[1796]       bound buffer[0] = 19550840
[1796][SQLExecute][1796]PGAPI_Execute: entering...
[1796]PGAPI_Execute: clear errors...
[1796]recycle statement: self= 22489384
[1796]APD_free_params:  ENTER, self=22489516
[1796]IPD_free_params:  ENTER, self=22489544
[1796]IPD_free_params:  EXIT
[1796]Exec_with_parameters_resolved: copying statement params:
trans_status=2, len=197, stmt='SELECT lkb.xge FROM lkb WHERE ((lkb.dgb =
'ek') AND (lkb.fgb = 'ik') AND (lkb.hgb = 'mk_kh')) ORDER BY
lkb.dgb,lkb.fgb,lkb.hgb'
[1796]   stmt_with_params = 'declare SQL_CUR01572928 cursor for SELECT
lkb.xge FROM lkb WHERE ((lkb.dgb = 'ek') AND (lkb.fgb = 'ik') AND (lkb.hgb =
'mk_kh')) ORDER BY lkb.dgb,lkb.fgb,lkb.hgb'
[1796]       Sending SELECT statement on stmt=22489384,
cursor_name='SQL_CUR01572928'
[1796]send_query(): conn=22495288, query='declare SQL_CUR01572928 cursor for
SELECT lkb.xge FROM lkb WHERE ((lkb.dgb = 'ek') AND (lkb.fgb = 'ik') AND
(lkb.hgb = 'mk_kh')) ORDER BY lkb.dgb,lkb.fgb,lkb.hgb'
[1796]send_query: done sending query
[1796]in QR_Constructor
[1796]exit QR_Constructor
[1796]read 17, global_socket_buffersize=4096
[1796]send_query: got id = 'C'
[1796]send_query: ok - 'C' - DECLARE CURSOR
[1796]send_query: setting cmdbuffer = 'DECLARE CURSOR'
[1796]send_query: returning res = 22519784
[1796]send_query: got id = 'Z'
[1796]QResult: in DESTRUCTOR
[1796]QResult: free memory in, fcount=0
[1796]QResult: free memory out
[1796]QResult: exit DESTRUCTOR
[1796]send_query(): conn=22495288, query='fetch 100 in SQL_CUR01572928'
[1796]send_query: done sending query
[1796]in QR_Constructor
[1796]exit QR_Constructor
[1796]read 85, global_socket_buffersize=4096
[1796]send_query: got id = 'P'
[1796]send_query: got id = 'T'
[1796]QR_fetch_tuples: cursor = 'SQL_CUR01572928', self->cursor=0
[1796]num_fields = 1
[1796]READING ATTTYPMOD
[1796]CI_read_fields: fieldname='xge', adtid=1043, adtsize=-1, atttypmod=-1
[1796]QR_fetch_tuples: past CI_read_fields: num_fields = 1
[1796]MALLOC: tuple_size = 100, size = 800
[1796]next_tuple: inTuples = true, falling through: fcount = 101,
fetch_count = 101
[1796]qresult: len=30, buffer='Thu, 7 Aug 2003 14:09:16 +0200'
[1796]end of tuple list -- setting inUse to false: this = 22519784
[1796]_next_tuple: 'C' fetch_total = 1 & this_fetch = 1
[1796]send_query: got id = 'Z'
[1796]     done sending the query:
[1796]extend_column_bindings: entering ... self=22489464,
bindings_allocated=1, num_columns=1
[1796]exit extend_column_bindings
[1796][[SQLEndTran]][1796]entering PGAPI_Transact: hdbc=22495288, henv=0
[1796]PGAPI_Transact: sending on conn 22495288 'COMMIT'
[1796]send_query(): conn=22495288, query='COMMIT'
[1796]send_query: done sending query
[1796]in QR_Constructor
[1796]exit QR_Constructor
[1796]read 9, global_socket_buffersize=4096
[1796]send_query: got id = 'C'
[1796]send_query: ok - 'C' - COMMIT
[1796]send_query: setting cmdbuffer = 'COMMIT'
[1796]send_query: returning res = 22526168
[1796]send_query: got id = 'Z'
[1796]QResult: in DESTRUCTOR
[1796]QResult: free memory in, fcount=0
[1796]QResult: free memory out
[1796]QResult: exit DESTRUCTOR
[1796][SQLCancel][1796]PGAPI_Cancel: entering...
[1796]PGAPI_FreeStmt: entering...hstmt=22489384, fOption=0
[1796]recycle statement: self= 22489384
[1796]QResult: in DESTRUCTOR
[1796]QResult: free memory in, fcount=1
[1796]row = 0, num_fields = 1
[1796]free [lf=0] 22489344
[1796]QResult: free memory out
[1796]QResult: exit DESTRUCTOR
[1796]APD_free_params:  ENTER, self=22489516
[1796]IPD_free_params:  ENTER, self=22489544
[1796]IPD_free_params:  EXIT
[1796]PGAPI_Cancel:  PGAPI_FreeStmt returned 0
[1796][SQLFreeStmt][1796]PGAPI_FreeStmt: entering...hstmt=22489384,
fOption=0
[1796]recycle statement: self= 22489384
[1796]APD_free_params:  ENTER, self=22489516
[1796]IPD_free_params:  ENTER, self=22489544
[1796]IPD_free_params:  EXIT
[1796][[SQLFreeHandle]][1796]PGAPI_FreeStmt: entering...hstmt=22489384,
fOption=1
[1796]SC_Destructor: self=22489384, self->result=0, self->hdbc=22495288
[1796]reset_a_column_binding: entering ... self=22489464,
bindings_allocated=1, icol=1
[1796]APD_free_params:  ENTER, self=22489516
[1796]IPD_free_params:  ENTER, self=22489544
[1796]IPD_free_params:  EXIT
[1796]SC_Destructor: EXIT


Appendix D:
-----------
The same as Appendix A, but with declarefetch=0:


00000009  16:35:38  [820] Detected PostgreSQL ODBC driver
00000010  16:35:38  [820] SQLAllocHandle(STMT) -->012E2048, 0
00000011  16:35:38  [820] SQLSetStmtAttr(012E2048,STATIC)-->0
00000012  16:35:38  [820] SQLPrepare(012E2048)-->0 [SELECT lkb.xge FROM lkb
WHERE ((lkb.dgb = 'ek') AND (lkb.fgb = 'ik') AND (lkb.hgb = 'mk_kh')) ORDER
BY lkb.dgb,lkb.fgb,lkb.hgb]
00000013  16:35:38  [820] bound columns
00000014  16:35:38  [820] SQLExecute(012E2048)-->0
00000015  16:35:38  [820] skipping getResultSize, returning 0
00000016  16:35:38  [820] SQLFetch(012E2048)-->0
00000017  16:35:38  [820] closeCursor/SQLFreeHandle(012E2048)-->0
00000018  16:35:38  [820] SQLFreeHandle(012E2048)-->0
00000019  16:35:38  [820] SQLAllocHandle(STMT) -->012E2048, 0
00000020  16:35:38  [820] SQLSetStmtAttr(012E2048,STATIC)-->0
00000021  16:35:38  [820] SQLPrepare(012E2048)-->0 [SELECT lkb.xge FROM lkb
WHERE ((lkb.dgb = 'ek') AND (lkb.fgb = 'ik') AND (lkb.hgb = 'kh_rij')) ORDER
BY lkb.dgb,lkb.fgb,lkb.hgb]
00000022  16:35:38  [820] bound columns
00000023  16:35:38  [820] SQLExecute(012E2048)-->0
00000024  16:35:38  [820] skipping getResultSize, returning 0
00000025  16:35:38  [820] SQLFetch(012E2048)-->100
00000026  16:35:38  [820] closeCursor/SQLFreeHandle(012E2048)-->0
00000027  16:35:38  [820] SQLFreeHandle(012E2048)-->0
00000028  16:35:38  [820] SQLAllocHandle(STMT) -->012E2048, 0
00000029  16:35:38  [820] SQLSetStmtAttr(012E2048,STATIC)-->0
00000030  16:35:38  [820] SQLPrepare(012E2048)-->0 [SELECT lkb.xge FROM lkb
WHERE ((lkb.dgb = 'ek') AND (lkb.fgb = 'ik') AND (lkb.hgb = 'mk_nk')) ORDER
BY lkb.dgb,lkb.fgb,lkb.hgb]
00000031  16:35:38  [820] bound columns
00000032  16:35:38  [820] SQLExecute(012E2048)-->0
00000033  16:35:38  [820] skipping getResultSize, returning 0
00000034  16:35:38  [820] SQLFetch(012E2048)-->0
00000035  16:35:43  [820] SQLAllocHandle(STMT) -->012E2480, 0
00000036  16:35:43  [820] SQLSetStmtAttr(012E2480,STATIC)-->0
00000037  16:35:43  [820] SQLPrepare(012E2480)-->0 [SELECT
vac.yzb,vac.aac,vac.cac,vac.eac FROM vac ORDER BY vac.aac]
00000038  16:35:43  [820] bound columns
00000039  16:35:43  [820] SQLExecute(012E2480)-->0
00000040  16:35:43  [820] skipping getResultSize, returning 0
00000041  16:35:43  [820] SQLFetch(012E2480)-->0
00000042  16:35:43  [820] SQLFetch(012E2480)-->100
00000043  16:35:43  [820] SQLAllocHandle(STMT) -->012E28B0, 0
00000044  16:35:43  [820] SQLSetStmtAttr(012E28B0,STATIC)-->0
00000045  16:35:43  [820] SQLPrepare(012E28B0)-->0 [SELECT qob.xge FROM qob
WHERE (qob.azc = 'to') ORDER BY qob.azc]

    *** etc. basically, all is fine as long as I can guarantee that I
        use tiny tables only (this is not the case)

--