Thread: Bug in latest ODBC driver (07.02.0004)

The 07.02.0004 (the ver. 3, non unicode in this case) driver has broken
some programs I have.  Attached is a snip from my ODBC log.

The basic problem seems to be that sending a 'create ...' statement to
the server and trying to get the row count after it executes causes
errors that shouldn't be happening.  The statement executes fine, as the
log shows, but SQLRowCount() returns -1 (SQL_ERROR).  There is also
aparently no error info saved because SQLGetDiagRecW() returns 100
(SQL_NO_DATA_FOUND).

Shouldn't SQLRowCount() succeed and return a row count of -1?

My platform is Win2k.

select version();
 PostgreSQL 7.2.1 on i686-pc-linux-gnu, compiled by GCC 2.96


Glen Parker
glenebob@nwlink.com

Glen Parker wrote:
>
> The 07.02.0004 (the ver. 3, non unicode in this case) driver has
> broken some programs I have.  Attached is a snip from my ODBC log.
>
> The basic problem seems to be that sending a 'create ...' statement
> to the server and trying to get the row count after it executes
> causes errors that shouldn't be happening.  The statement executes
> fine, as the log shows, but SQLRowCount() returns -1 (SQL_ERROR).
> There is also aparently no error info saved because
> SQLGetDiagRecW() returns 100 (SQL_NO_DATA_FOUND).
>
> Shouldn't SQLRowCount() succeed and return a row count of -1?

You seem to be right. I would commit the change.
Also try the snapshot dll at http://w2422.nsk.ne.jp/~inoue/.

Thanks.
Hiroshi Inoue

> > Shouldn't SQLRowCount() succeed and return a row count of -1?
>
> You seem to be right. I would commit the change.
> Also try the snapshot dll at http://w2422.nsk.ne.jp/~inoue/.

That did it.  Thx.
And yes, please commit.  There seems to be another bug fixed in current
CVS and I'd like to get a fresh build with this latest fix and continue
my testing.

Glen Parker
glenebob@nwlink.com

Glen Parker wrote:
>
> > > Shouldn't SQLRowCount() succeed and return a row count of -1?
> >
> > You seem to be right. I would commit the change.
> > Also try the snapshot dll at http://w2422.nsk.ne.jp/~inoue/.
>
> That did it.  Thx.
> And yes, please commit.  There seems to be another bug fixed in current
> CVS and I'd like to get a fresh build with this latest fix and continue
> my testing.

OK I've just committed the change.

regards,
Hiroshi Inoue
    http://w2422.nsk.ne.jp/~inoue/

This bug *seems* to be the result of incomplete statement recycling (old
values left behind from previous executions).  This is mostly a guess.
Log is attached.

If a non-select statement is executed (INSERT in this case) followed by
a select, trying to fetch the rows from the select will fail with an
invalid scroll type error.

Compiling the driver without the DRIVER_CURSOR_IMPLEMENT flag eliminates
the errors.  Turning updatable cursors on/off in the driver config has
no apparent affect.

Glen Parker
glenebob@nwlink.com

Glen Parker wrote:
>
> This bug *seems* to be the result of incomplete statement recycling (old
> values left behind from previous executions).  This is mostly a guess.
> Log is attached.
>
> If a non-select statement is executed (INSERT in this case) followed by
> a select, trying to fetch the rows from the select will fail with an
> invalid scroll type error.
>
> Compiling the driver without the DRIVER_CURSOR_IMPLEMENT flag eliminates
> the errors.  Turning updatable cursors on/off in the driver config has
> no apparent affect.

I committed a change to cvs though I tested none about it.
Could you try it ? Please nmake clean before rebuilding it.

regards,
Hiroshi Inoue
    http://w2422.nsk.ne.jp/~inoue/