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

Another bug with parse statements on

From: "Andrea Aime" <aaime(at)comune(dot)modena(dot)it>
To: Postgres ODBC <pgsql-odbc(at)postgresql(dot)org>
Subject: Another bug with parse statements on
Date: 2001-04-20 10:50:42
Message-ID: 3AE01482.61DB17F7@comune.modena.it (view raw or flat)
Thread:
Lists: pgsql-odbc
Hi everybody,
I've just come up with another bug... my last solution was to 
apply my tiny bug fix on searchColInfo and keep "parse statements" = 1
Unfortunately this breaks another query, I think because the parser
has some problem with the "as" keyword... With "parse statements" = 1
the following query, issued from VB (using ADO 2.6), fails:

'SELECT min(classe) as minimo, max(classe) as massimo
FROM tav974'
(
 is a carriage return...)

I have found a quick fix, but it may work only in my environment.
1) Set "parse statements" = 0
2) Modify every occurence of:

if (globals.parse && stmt->statement_type == STMT_TYPE_SELECT)

into

if ((globals.parse || stmt->prepare) && stmt->statement_type ==
STMT_TYPE_SELECT)

in results.c. 

This forces parsing on every prepared statement but avoids it on every
other
statement. Now my programs are working, but if something would issue a
prepared
statement like:

SELECT min(classe) as minimo, max(classe) as massimo
FROM tav974
where dummycol=?

the driver would fail. I have a mylog file with all the messages that
relates
to the mentioned bug, if you want I can send it to you (10kb if
compressed with
winzip). Sorry, but I have no time now to track down also this one...
maybe
it's stuff for someone more experienced than me.
Regards
Andrea Aime

Responses

pgsql-odbc by date

Next:From: Dmitry SeleznevDate: 2001-04-20 11:52:08
Subject:
Previous:From: Dmitry SeleznevDate: 2001-04-20 10:33:17
Subject: ODBC making trobles

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