Re: Some changes - Mailing list pgsql-odbc

From Dave Page
Subject Re: Some changes
Date
Msg-id E7F85A1B5FF8D44C8A1AF6885BC9A0E4E7E5E5@ratbert.vale-housing.co.uk
Whole thread Raw
In response to Some changes  (Ludek Finstrle <luf@pzkagis.cz>)
Responses Re: Some changes
List pgsql-odbc

> -----Original Message-----
> From: Ludek Finstrle [mailto:luf@pzkagis.cz]
> Sent: 02 December 2005 12:29
> To: Dave Page
> Subject: Re: [ODBC] Some changes
>
> I'll investigate it more in afternoon or tomorrow.
> It seems to me that after succesful run app calls FreeStmt.
> But after SQLCancel it doesn't. Have to we call it in SQLCancel?
> Not only FreeStmt with SQL_Close but with SQL_DROP?
> It sounds me to be too much brutal. It's the point I don't know
> how describe it ODBC spec.
>
> I'm at work now and I have no access to source code.

OK, here's what seems to be happening:

1) The app allocates a statement
2) The app binds 3 parameters using SQLBindParameter. 2 are given
values, and the third (the text column) is set to data_at_exec.
3) The app calls SQLExecDirectW, with a statement containing 3
parameters. The driver returns SQL_NEED_DATA (because it has no data for
param 3 yet).
4) SQLParamData is called to supply the required data and the query is
executed.
5) The server returns SQL_ERROR because of a unique index violation.
6) The app calls SQLCancel.
7) The app calls SQLExecDirectW with a query containing no parameters
*on the same statement handle*. The driver returns SQL_NEED_DATA,
because it still has a bound parameter set to data_at_exec.
8) Foxpro barfs, not expecting SQL_NEED_DATA.

The attached patch clears out any parameters during SQLCancel. This
works for the test case, and seems to not hurt any of my apps that I've
quickly tested. I definitely want some feedback before I apply this
though please :-)

Regards, Dave.

Attachment

pgsql-odbc by date:

Previous
From: Ludek Finstrle
Date:
Subject: Re: Application crash after error
Next
From: Ludek Finstrle
Date:
Subject: Re: Some changes