Re: Snapshot 08.01.0006 available for testing - Mailing list pgsql-odbc

"Dave Page" wrote:

>> >> SQL command: "SELECT col1 FROM table WHERE col2=?"
>> >> (Note: col1 is a SERIAL, col2 a VARCHAR).
>> >>
>> >> Bind the input [SQLBindParameter] and output [SQLBindCol]
>> >> parameter before
>> >> calling SQLPrepare().
>> >>
>> >> The following call to SQLExecute() returns SQL_SUCCESS. But
>> >> the first call to
>> >> SQLFetch() produces this error message:
>> >> <1> {HY010}(3) Null statement result in PGAPI_ExtendedFetch.

(...)

>Sorry - when I first read both messages I somehow managed to parse
>ServerSidePrepare as UsedeclareFetch :-(
>
>Yes, it does seem to be broken - the earlier fixes were for Use
>Declare/Fetch, so I'm not overly surprised it remains broken.
>
>I'll look into it, however given that it's not a widely used option (and
>isn't documented either), I'm still inclined to release 08.01.whatever
>even if we can't figure out the correct fix in time. It's definitely a
>less broken driver than the current stable release.

That's no problem. The 08.01.006 driver is working without
"ServerSidePrepare"; it's just a performance issue.

However, I just turned on "UsedeclareFetch" to see if it works. There are
_lots_ of memory leakages (in repeating patterns) when my program exits (see
below). They all vanish if "UsedeclareFetch" is disabled. Seems like this is
related to memory not freed in class QResultClass.

Apart from that it seems to work, although I haven't done any stress tests.
But I might find some time tomorrow to check it more thoroughly.

Rainer


 Data: <ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ> FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
 Data: <        > 00 00 00 00 00 00 00 00
 Data: <@ @   ÿ > 40 00 40 00 01 00 FF 0F
 Data: <                > 13 00 00 00 13 00 00 00 12 00 00 00 19 00 00 00
 Data: <@vC  vC ÀuC €uC > 40 76 43 01 00 76 43 01 C0 75 43 01 80 75 43 01
 Data: <  ÍÍ0xC ðwC  wC > 04 00 CD CD 30 78 43 01 F0 77 43 01 00 77 43 01
 Data: <pxC 0uC xÜ9     > 70 78 43 01 30 75 43 01 78 DC 39 01 00 00 00 00
 Data: <ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ> CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
 Data: <SQL_CUR01430070 > 53 51 4C 5F 43 55 52 30 31 34 33 30 30 37 30 00
 Data: <fetch 100 in SQL> 66 65 74 63 68 20 31 30 30 20 69 6E 20 53 51 4C
 Data: <coalesce > 63 6F 61 6C 65 73 63 65 00
 Data: <relkind > 72 65 6C 6B 69 6E 64 00
 Data: <nspname > 6E 73 70 6E 61 6D 65 00
 Data: <relname > 72 65 6C 6E 61 6D 65 00
 Data: <ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ> FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
 Data: <        > 00 00 00 00 00 00 00 00
 Data: <@ @   ÿ > 40 00 40 00 01 00 FF 0F
 Data: <                > 13 00 00 00 13 00 00 00 12 00 00 00 19 00 00 00
 Data: < zC àyC  yC `yC > 20 7A 43 01 E0 79 43 01 A0 79 43 01 60 79 43 01
 Data: <  Í̀ C À{C €{C > 04 00 CD CD 80 0B 43 01 C0 7B 43 01 80 7B 43 01
 Data: <€ C  yC xÜ9     > 80 7F 43 01 10 79 43 01 78 DC 39 01 00 00 00 00
 Data: <ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ> CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
 Data: <SQL_CUR01430DC0 > 53 51 4C 5F 43 55 52 30 31 34 33 30 44 43 30 00
 Data: <fetch 100 in SQL> 66 65 74 63 68 20 31 30 30 20 69 6E 20 53 51 4C
 Data: <coalesce > 63 6F 61 6C 65 73 63 65 00
 Data: <relkind > 72 65 6C 6B 69 6E 64 00
 Data: <nspname > 6E 73 70 6E 61 6D 65 00
 Data: <relname > 72 65 6C 6E 61 6D 65 00