Hi BP--
There's also named cursors, but then you're going to have the problem of
time. That is if you create a cursor FOR UPDATE and the user never saves
the record or never cancels the edit (just closes her browser, for
instance), then you're messed up and have locks floundering around in the d
On Wed, 29 Aug 2001 03:18:01 -0400, [EMAIL PROTECTED] (Doug Semig)
wrote:
>0. User A loads Record R.
>1. User B loads Record R.
>2. User B edits and saves Record R.
> (Saving involves starting a transaction, retrieving R from the DB,
>comparing the values with the original values to make su
Hi BP--
0. User A loads Record R.
1. User B loads Record R.
2. User B edits and saves Record R.
(Saving involves starting a transaction, retrieving R from the DB,
comparing the values with the original values to make sure it is
the same record, and then the UPDATE and then commit