Thread: ODBC driver failure
Hello, ODBC driver fail (raise exception) with these steps: 1) SQLPrepare (SELECT relname FROM pg_class WHERE relname != ?) 2) SQLExecute I found the bug and fix it. Patch is attached. Regards Luf
Attachment
> -----Original Message----- > From: pgsql-odbc-owner@postgresql.org > [mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Ludek Finstrle > Sent: 05 December 2005 15:17 > To: pgsql-odbc@postgresql.org > Subject: [ODBC] ODBC driver failure > > Hello, > > ODBC driver fail (raise exception) with these steps: > 1) SQLPrepare (SELECT relname FROM pg_class WHERE relname != ?) > 2) SQLExecute > > I found the bug and fix it. Patch is attached. Thanks Luf, patch applied. BTW, did I understand from your earlier email that you are still looking at the other server side prepare issue we've been discussing with Rainer, or is the last patch good in your opinion? Regards, Dave.
> BTW, did I understand from your earlier email that you are still looking
> at the other server side prepare issue we've been discussing with
> Rainer, or is the last patch good in your opinion?
I think psqlodbc-server_side_prepare.diff and
psqlodbc_server_side_prepare2.diff are good enough. But I'm waiting if
Rainer send steps which leads to bug.
BTW do you know why ExecDirect test open cursor? I'm talking about
SELECT statements. Cursor is opened in PGAPI_Execute so there can't
be called ExecDirect after Execute or ExecDirect. There is no limitation
for calling Execute, Prepare, Execute :-( Check in SQLDirect is done
by SC_opencheck:
if (res = SC_get_Curres(self), NULL != res)
{
if (res->backend_tuples)
{
SC_set_error(self, STMT_SEQUENCE_ERROR, "The cursor is open.");
SC_log_error(func, "", self);
return TRUE;
}
}
I have no idea why is it doing this way :-(
Luf
> -----Original Message-----
> From: Ludek Finstrle [mailto:luf@pzkagis.cz]
> Sent: 05 December 2005 17:01
> To: Dave Page
> Cc: pgsql-odbc@postgresql.org
> Subject: Re: [ODBC] ODBC driver failure
>
> > BTW, did I understand from your earlier email that you are
> still looking
> > at the other server side prepare issue we've been discussing with
> > Rainer, or is the last patch good in your opinion?
>
> I think psqlodbc-server_side_prepare.diff and
Which ones that one? - I lost track :-(
> psqlodbc_server_side_prepare2.diff are good enough. But I'm waiting if
> Rainer send steps which leads to bug.
Got that one.
> BTW do you know why ExecDirect test open cursor? I'm talking about
> SELECT statements. Cursor is opened in PGAPI_Execute so there can't
> be called ExecDirect after Execute or ExecDirect. There is no
> limitation
> for calling Execute, Prepare, Execute :-( Check in SQLDirect is done
> by SC_opencheck:
> if (res = SC_get_Curres(self), NULL != res)
> {
> if (res->backend_tuples)
> {
> SC_set_error(self, STMT_SEQUENCE_ERROR, "The
> cursor is open.");
> SC_log_error(func, "", self);
> return TRUE;
> }
> }
> I have no idea why is it doing this way :-(
No, nor do I offhand. I'm really busy at the moment though - do you have
time to investigate further please?
Thanks, Dave.
> > I think psqlodbc-server_side_prepare.diff and > > Which ones that one? - I lost track :-( This is included in psqlodbc-08.01.0102. > > psqlodbc_server_side_prepare2.diff are good enough. But I'm waiting if > > Rainer send steps which leads to bug. > > Got that one. Do you mean diff or sequence of steps? > time to investigate further please? I have a lot of other work. Maybe later. There is problem with bytea, Autocommit and Cancel, ColAttribure (maybe this is problem of VB6 RowCount). When there is no one report it. I didn't investigate it in near future. And there is question of cleaning old unused code. Luf
On 5/12/05 6:06 pm, "Ludek Finstrle" <luf@pzkagis.cz> wrote: >>> I think psqlodbc-server_side_prepare.diff and >> >> Which ones that one? - I lost track :-( > > This is included in psqlodbc-08.01.0102. Ah that one- thanks. >>> psqlodbc_server_side_prepare2.diff are good enough. But I'm waiting if >>> Rainer send steps which leads to bug. >> >> Got that one. > > Do you mean diff or sequence of steps? Diff. I'll apply it tomorrow. >> time to investigate further please? > > I have a lot of other work. Maybe later. > There is problem with bytea, Autocommit and Cancel, ColAttribure (maybe > this is problem of VB6 RowCount). > When there is no one report it. I didn't investigate it in near future. > And there is question of cleaning old unused code. Yeah. We'll get there in the end!!! Regards, Dave
> > BTW do you know why ExecDirect test open cursor? I'm talking about
> > SELECT statements. Cursor is opened in PGAPI_Execute so there can't
> > be called ExecDirect after Execute or ExecDirect. There is no
> > limitation
> > for calling Execute, Prepare, Execute :-( Check in SQLDirect is done
> > by SC_opencheck:
> > if (res = SC_get_Curres(self), NULL != res)
> > {
> > if (res->backend_tuples)
> > {
> > SC_set_error(self, STMT_SEQUENCE_ERROR, "The
> > cursor is open.");
> > SC_log_error(func, "", self);
> > return TRUE;
> > }
> > }
> > I have no idea why is it doing this way :-(
>
> No, nor do I offhand. I'm really busy at the moment though - do you have
> time to investigate further please?
I'm studying ODBC specification and I find answer. psqlODBC behaviour is
right. The app have to close cursor prior to Execute new query.
So this is done ;-)
Luf
> -----Original Message-----
> From: Ludek Finstrle [mailto:luf@pzkagis.cz]
> Sent: 14 December 2005 14:11
> To: Dave Page
> Cc: pgsql-odbc@postgresql.org
> Subject: Re: [ODBC] ODBC driver failure
>
> > > BTW do you know why ExecDirect test open cursor? I'm talking about
> > > SELECT statements. Cursor is opened in PGAPI_Execute so
> there can't
> > > be called ExecDirect after Execute or ExecDirect. There is no
> > > limitation
> > > for calling Execute, Prepare, Execute :-( Check in
> SQLDirect is done
> > > by SC_opencheck:
> > > if (res = SC_get_Curres(self), NULL != res)
> > > {
> > > if (res->backend_tuples)
> > > {
> > > SC_set_error(self, STMT_SEQUENCE_ERROR, "The
> > > cursor is open.");
> > > SC_log_error(func, "", self);
> > > return TRUE;
> > > }
> > > }
> > > I have no idea why is it doing this way :-(
> >
> > No, nor do I offhand. I'm really busy at the moment though
> - do you have
> > time to investigate further please?
>
> I'm studying ODBC specification and I find answer. psqlODBC
> behaviour is
> right. The app have to close cursor prior to Execute new query.
> So this is done ;-)
:-)
/D