| 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: | Whole Thread | Raw Message | 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
| 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 |