"Hilmar Retief" <hretief@hotmail.com> wrote in message <news:3a9e64a2$1@news.devx.com>...

> Trying not expose my serious lack of expertise on DB mechanics , but
> here's how I understand it. With ADO (and SQL Server), after the process
> above succeeded, and the HoldFld's for the 2 users are the same and they are
> both doing the update at the same instant, ADO provides an "Optimistic Batch
> Locking" mechanism, which will only allow one update to occur and the second
> will be bounced back to the user. With say DB2 also being a 2-phase commit

You mean you're using updating through Recordset objects? For shame! All
the self-proclaimed "gurus" tell us to use SQL UPDATE statements to just
blindly zap the records no matter what may have happened to it since the
last read! Haven't you been paying attention in the overpriced seminars?

> DB I guess the same applies to it's DBMS. Adabas(not 2-phase commit) is
> more interesting though. It relies heavily on it's built in language
> (Natural). It will only attempt to lock a record when the
> requesting(natural) program has both a "read" and an "update" statement in
> the same program construct.

Maybe there's a "repeatable read" setting for the "isolation level". If
you use this in your update methods, while you have a recordset open,
nobody else may mangle its underlying records, making the SQL UPDATE
statement safe to use. I'd use the "repeatable read" mojo solely for
checking the timestamp or HoldFld, though.

Joe Foster <mailto:jfoster@ricochet.net> Got Thetans? <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!