Thread: queries run twice unless 'parse statements' checked?

queries run twice unless 'parse statements' checked?

From
"Johann"
Date:
Running PostgreSQL 8.0, client is Visual Basic program using ADO, test case
has one adodc and a bound grid.

Queries involving a 188,000 row table were slow, even when query was on
single value in uniquely keyed index.

Turns out - from checking the plsqlodbc file, it was executing the query
once like I said:

select something from somewhere where thing=value

[returning one row]

then it ran the query again without the where clause [really!]

SELECT something FROM somewhere (The second query had the keywords turned
to upper case, if that helps identify what's going on.)

[returning 188,000 rows]

Naturally, this made things run slowly.  I fiddled around and eventually
found that by checking "Parse Statements", this behavior stopped.

Anyway - is it supposed to work this way?

    - Johann


Re: queries run twice unless 'parse statements' checked?

From
"Dave Page"
Date:

> -----Original Message-----
> From: pgsql-odbc-owner@postgresql.org
> [mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Johann
> Sent: 07 February 2005 04:20
> To: pgsql-odbc@postgresql.org
> Subject: [ODBC] queries run twice unless 'parse statements' checked?
>
> Running PostgreSQL 8.0, client is Visual Basic program using
> ADO, test case
> has one adodc and a bound grid.
>
> Queries involving a 188,000 row table were slow, even when
> query was on
> single value in uniquely keyed index.
>
> Turns out - from checking the plsqlodbc file, it was
> executing the query
> once like I said:
>
> select something from somewhere where thing=value
>
> [returning one row]
>
> then it ran the query again without the where clause [really!]
>
> SELECT something FROM somewhere (The second query had the
> keywords turned
> to upper case, if that helps identify what's going on.)
>
> [returning 188,000 rows]
>
> Naturally, this made things run slowly.  I fiddled around and
> eventually
> found that by checking "Parse Statements", this behavior stopped.
>
> Anyway - is it supposed to work this way?

I cannot reproduce this behaviour here using a simple ADO recordset -
but can with the ADODC. My guess is that it is running the query again
to get column definitions (which happens automatically - and doubtless
more efficiently - with parse turned on) so that it can figure out how
to build update queries etc.

Regards, Dave,