Re: Using views and MS access via odbc

From: "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Ron Snyder" <snyder(at)roguewave(dot)com>, <pgsql-general(at)postgresql(dot)org>, "pgsql-hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Using views and MS access via odbc
Date: 2002-05-02 22:52:05
Message-ID: EKEJJICOHDIEMGPNIFIJAEBLHLAA.Inoue@tpf.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

> -----Original Message-----
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
>
> Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> writes:
> > Your settings probably worked well under 7.1 but
> > doesn't in 7.2 due to the following change in
> > tcop/postgres.c.
>
> AFAIR, there is only a visible change of behavior for
> INSERT/UPDATE/DELETE queries, not for SELECTs. So I don't think
> this change explains Ron's complaint.

For a view a_view

UPDATE a_view set ... where xxxxx;
returns UPDATE 0 in any case in 7.2.

The psqlodbc driver understands that no row was updated
and returns the info to the upper application if requested.
MS access( and I) think there's no such case other than
the row was changed or deleted after it was SELECTed.
Note that MS access doesn't issue any SELECT commands
to check the optimistic concurrency of the row. The where
clause of the UPDATE command contains *a_item = old_value*
for all items to check the optimisitic concurrency at the
same time.

regards,
Hiroshi Inoue

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Kym Farnik 2002-05-02 23:38:08 DLM Oracle/Compaq/OpenVMS
Previous Message Paul M Foster 2002-05-02 22:50:21 Re: Fwd: Postfix Relay Hub SMTP server: errors from postgresql.org[64.49.215.8]

Browse pgsql-hackers by date

  From Date Subject
Next Message Manfred Koizar 2002-05-02 23:25:26 Re: Per tuple overhead, cmin, cmax
Previous Message Scott Marlowe 2002-05-02 22:14:45 Re: PostgreSQL mission statement?