Skip site navigation (1) Skip section navigation (2)

Re: Bug in clear_error in SQLExecute?

From: "'Ludek Finstrle'" <luf(at)pzkagis(dot)cz>
To: Hiroshi Inoue <inoue(at)tpf(dot)co(dot)jp>
Cc: "'Ludek Finstrle'" <luf(at)pzkagis(dot)cz>, pgsql-odbc(at)postgresql(dot)org
Subject: Re: Bug in clear_error in SQLExecute?
Date: 2004-01-10 14:12:36
Message-ID: 20040110141236.GA19067@soptik.pzkagis.cz (view raw or flat)
Thread:
Lists: pgsql-odbc
> 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

In response to

pgsql-odbc by date

Next:From: Sven KöhlerDate: 2004-01-12 18:02:36
Subject: psqlodbc msi version 7.3.200
Previous:From: Hiroshi InoueDate: 2004-01-10 13:22:55
Subject: Re: Bug in clear_error in SQLExecute?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group