Re: basic questions with odbc and visual basic.

From: "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com>
To: "Jeff Eckermann" <jeff_eckermann(at)yahoo(dot)com>
Cc: <pgsql-odbc(at)postgresql(dot)org>
Subject: Re: basic questions with odbc and visual basic.
Date: 2004-09-29 15:05:50
Message-ID: 6EE64EF3AB31D5448D0007DD34EEB3412A74DA@Herge.rcsinc.local
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-odbc

> Access (can't answer for VB) handles concurrency on
> updates by checking whether the data has changed since
> the row was first fetched. If you have a unique rowid
> (which is what "row versioning" implies), then that is
> used for comparison (the psqlodbc driver uses the ctid
> value for that). Otherwise, every field is checked,
> as you were seeing. If any of the data has changed,
> the row is presumed to have been changed by another
> user in the meantime, and the update will fail with an
> error message saying so.
>
> The problem with timestamps is that Access does not
> handle fractional seconds, whereas PostgreSQL
> timestamps do by default, so timestamp comparisons
> become problematic. None of my apps require
> fractional seconds resolution, so I usually use
> timestamp(0) for tables that I know will be used by an
> Access application.

Yep. I do the same thing for tables accessed by deplhi apps. There
could also be a problem with really large numerics (many client app
technologies use float or double internal representation) but this comes
up less often. The row versioning tip was incredibly helpful however.

Merlin

Browse pgsql-odbc by date

  From Date Subject
Next Message amir 2004-09-29 23:58:28 \n converted to \r\n
Previous Message Peter Kelly 2004-09-29 14:03:12 Re: psqlODBC hangs