--- Merlin Moncure <merlin.moncure@rcsonline.com>
wrote:
> > Do you have driver option "Row Versioning" set to
> > true? I'm vague on the details, but I suspect
> that
> > may help.
> >
>
> That did the trick...bless you.
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.
This is all overview; I have no idea where in the
chain this is implemented.
>
> FWIW, I tracked down the failed updates to Access
> chopping timestamp
> column to nearest second (note: this was not a field
> I was trying to
> update). The timestamp was wrapped in a domain
> which may have caused
> the problem. Have confirmed both successful edit of
> regular table in
> both access and vb.
>
> Merlin
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
>
> http://www.postgresql.org/docs/faqs/FAQ.html
>
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail