Skip site navigation (1) Skip section navigation (2)

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 (view raw, whole thread or download thread mbox)
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.


pgsql-odbc by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group