Re: Snapshot 08.01.0006 available for testing

From: Rainer Bauer <usenet(at)munnin(dot)com>
To: pgsql-odbc(at)postgresql(dot)org
Subject: Re: Snapshot 08.01.0006 available for testing
Date: 2005-11-03 18:01:54
Message-ID: buikm1h6hsi4e13vsavvcc9ljvsv29886q@4ax.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-odbc by date

  From Date Subject
Next Message Marko Ristola 2005-11-03 19:21:36 Re: Snapshot 08.01.0006 available for testing
Previous Message Brent Gorda 2005-11-03 16:53:01 Troubles with odbc on Solaris 10 (x86)