> 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