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 or flat)
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

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-2014 The PostgreSQL Global Development Group