Re: oracle concurrent
Date: 1996/02/06
Message-ID: <richard_avery_cnt40791-060296153050_at_nnsgm25.lon40.nt.com>#1/1
[Snip]
> >In article <310FAE65.1232_at_us.oracle.com>, "Robert C. Nix"
> ><rnix_at_us.oracle.com> writes
> >>> lee (lee_at_cnct.com) wrote:
> >>> problem:
> >>> how to avoid two user SELECT same data from database,
> >>> and one's UPDATE + COMMIT overwrite another one's UPDATE +
> >>> COMMIT ?
> >>> we don't want lock the row after SELECT, but want lock
> >>> the row after UPDATE, and before COMMIT, how to do
> >>> this ?
> >>> Thank you.
> >>
[Snip]
A programmer should not have to be concrened with such time based
conflicts. The only time such a situation should arise is where user in put
is required - i.e. in a screen. In forms Oracle handles data concurrency
for you, forms would attempt to lock the rows only when the user types a
change into a form field, the row would then quite coirrectly be
unchangeable by any other user until the changes are commited or rolled
back.
Any batch process updating rows should take out an update lock when data is selected.
Richard Avery
-- The above posting does not represent the views of Nortel in any way.Received on Tue Feb 06 1996 - 00:00:00 CET