> David Ciarniello wrote:
> > I found some bugs working with Access'97-ODBC 7.006 on a Win98 client
> > 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, ...
> > 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 ..
> > (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
> > 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
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
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 :-))
In response to
pgsql-odbc by date
|Next:||From: Hiroshi Inoue||Date: 2001-07-06 02:29:21|
|Subject: Re: R: ODBC 7.0006 bugs|
|Previous:||From: Hiroshi Inoue||Date: 2001-07-05 23:44:52|
|Subject: Re: ODBC 7.0006 bugs|