> David Ciarniello wrote:
> >
> > I found some bugs working with Access'97-ODBC 7.006 on a Win98 client
and
> > PostgreSQL 7.1.2 on a Redhat 6.2 server:
> >
> > 1) subselect side-effects:
> > if I run the following query:
> >
> > select expr1 as field1, expr2 as field2, ... expr-j as field-j, ...
expr-n
> > as field-n;
> > where expr-j is a subselect (e.g. select count(*) from table_x)
> >
> > I only have results for columns 1 .. j . the driver omits columns j+1 ..
n
> > (all the columns subsequent the subselect expression)
>
> You seem to turn on *Parse Statements* option setting.
> psqlodbc driver doesn't parse compilcated queries well.
> OK I will take care of this.
Yes. Disabling the "Parse Statement" it works fine! Thank you.
But now I have to create a third driver installation, with a datasource
dedicated only to pass-through queries because "Parse Statement" is a
driver-based setting :-((
>
> > 2) updating a table without row versioning:
> >
> > I can't update a table with a float field (but the problem could affect
also
> > other kind of fields) with row-versioning deactivated.
>
> It's a known issuea and psqlodbc driver isn't guilty.
> If row-versioning is activated, appications could use
> an optimistic concurrency control using row versions,
> otherwise they have to use an optimistic concurrency
> control using values.
> The main problem is that PostgreSQL servers doesn't
> return float values with sufficient precisions.
> For example, float4 -> 6, float8 -> 15.
>
Now I understood a thing that appeared weird to me; the driver uses all
fields to identify a row (even if there's a unique column) to avoid
concurrent changes.
I think that the problem could be solved identifying some fields with a
between operator (with a very small range) instead of an equal (=) operator;
this just to workaround the problem.
Let's say that the backend returns
a.bcde
you can identify the field with a condition
field between a.bcde and a.bcde9
The probability of a collision is quite the same as with the = operator.
The same rule (of course changed) could be applied with all other datatypes
that create this kind of problems.
Of course it's enormously simpler to adopt the row versioning technique :-))
Regards,
David Ciarniello