Re: oracle concurrent

From: Richard Avery <richard_avery_cnt40791_at_nt.com>
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

Original text of this message