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 db.
In the HTTP stateless scenario, you really do want to do everything within
the timespan of a single page-view. Dave Watkinson's suggestion for a
column in the table to store some kind of version info (a timestamp or some
other identifier that is updated every time the record changes) is a good
one because it makes detecting an updated row a lot easier than comparing
all of the original values from the originally loaded record to what's
there when you finally go to save it.
However, there may be times when Dave's suggestion can be overly
restrictive. Let's say User A changes one column of Record R and User B
changes a different column of Record R. In that case, the changes do not
step on each other and probably should be allowed. Dave's suggestion for a
per-record version identifier would kick out the 2nd person to save the
record's edits with the "this record has been changed by another user or
process" message. Perhaps that's correct for your application, perhaps it
is not. You and your customer have to decide.
That's why I tend to compare the originally loaded values of the fields
that have been changed by the user with the fields as they appear in the
record during the transaction that UPDATEs the record. If they're
different then those fields really have been modified by another user or
process and the transaction should be abandoned until the user gets a
chance to review the situation.
Hope this helps,
Doug
At 12:13 PM 8/29/01 GMT, Bopolissimus Platypus wrote:
>On Wed, 29 Aug 2001 03:18:01 -0400, [EMAIL PROTECTED] (Doug Semig)
[--snip--]
>thanks. that was one of the alternatives i'd been considering.
>heh, i was trying to avoid the complexity. after all, if the database
>already has locking and data consistency built-in, why reinvent
>the wheel, right? but that denial of service thing is a problem
>(and it would be a SELF-denial-of-service :). thanks for voting
>for this alternative. i'll wait a few days for others to comment
>and maybe provide alternatives before committing to one
>approach :).
>
>tiger
[--snip--]
--Doug's Signature File----------------------------------------
~ ~ ~ I'm proud to work for GLISnet, Michigan's best ISP ~ ~ ~
--1.888.445.4763---8am to 8pm every day---http://www.glis.net--
The views and opinions expressed in this email are my
own and may not be those of my employer.
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
