Thread: Bug in clear_error in SQLExecute?

Hello,

  I think I found a bug in SQLExecute. IMHO SC_clean_error should be
called there only sometimes as you can see from my patch created
againist fresh CVS snapshot.

Without this patch application fail becouse error is produced in Fetch
instead of in Execute.

Commments are welcome

Luf

> -----Original Message-----
> Ludek Finstrle
>
> Hello,
>
>   I think I found a bug in SQLExecute. IMHO SC_clean_error should be
> called there only sometimes as you can see from my patch created
> againist fresh CVS snapshot.
>
> Without this patch application fail becouse error is produced in Fetch
> instead of in Execute.

Could you explain the examples ?

regards,
Hiroshi Inoue

> Hiroshi Inoue
>
> > Ludek Finstrle
> >
> >   I think I found a bug in SQLExecute. IMHO SC_clean_error should be
> > called there only sometimes as you can see from my patch created
> > againist fresh CVS snapshot.
> >
> > Without this patch application fail becouse error is produced in Fetch
> > instead of in Execute.
>
> Could you explain the examples ?

I can. I attach part of mylog output where the problem is described.
I try explain it in english and I hope you can understand.

Application call select on non-exists table. It's allocate stmt then
it prepare stmt. Then it call NumResultCols. Error raise in this
function but it return SQL_SUCCESS (I think this is right) and set
stmt status to STMT_PREMATURE. Then it call Execute. There is
clean_error so it return SQL_SUCCES and I think this is wrong>.
After it app call Fetch and it fail.

Application doesn't expect failure in Fetch after success execute.
I don't have source for app because it's commercial one. So I can't
change it's behaviour. I tried create table but app fails later.

When I patch psqlodbc it's doing what I expect. But I'm not sure
if it's good for all situations. I don't see so far.

The opposite one situation which I think about is execute twice or
more times with different binding parameters. So I add test status
to STMT_FINISHED. As I said I'm not sure if it's correct.

Best regards

Luf