Dick explained the locks, I'll talk a little about how I've
used it and seen it used.
In an user application, doing a SELECT FOR UPDATE and
letting the user update the data in the form at his or her leisure
and then COMMIT the data is very bad practice. Sounds kind
of like Designer 2000 in that regard.
Anyway, the user selects the data, goes to lunch. You then
get frantic calls on how the database is 'broken'.
The typical way to deal with this is to select the data into the
user app, let the user modify the data, then do another select
to determine if someone else has changed the data while
your user was monkeying with it.
If the data has changed, issue a warning, let them see the
changes, whatever, then let the user decide what to do, which
is usually to abort the changes.
Oracle Forms will do this checking for you automatically, saving
you a fair amount of complex coding.
Jared
On Wednesday 09 May 2001 09:26, SuzyV wrote:
> What are the negatives of using 'select for update'? Seem to recall it
> locks all rows within a block causing other transactions to wait on rows
> needed in the same block. What about performance impacts??
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Jared Still
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
