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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Dmitry Seleznev | 2001-04-20 11:52:08 | |
Previous Message | Dmitry Seleznev | 2001-04-20 10:33:17 | ODBC making trobles |