nd not once was it even close.
>
>
> what is the update statement you want to put inside the cursor?
>
> > From: MaryAnn Atkinson <[EMAIL PROTECTED]>
> > Date: 2003/07/11 Fri PM 04:09:25 EDT
> > To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]>
> >
Hi!
> Actually, it is the FOR UPDATE that locks the table.
No, for update still locks *only the rows* selected with for update clause.
All other parts of table are available for both reading AND writing (of
course if other transactions don't have locks on some rows).
And you can read the whol
Title: RE: full usefullness of CURRENT OF ???
Locking if something oracle is very good at. It happens all over the place and it happens quickly...there is very little overhead to it.
Block headers. ...each block in the affected table.
By updating the table by rowid, you get the
Fri PM 04:09:25 EDT
> To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]>
> Subject: RE: full usefullness of CURRENT OF ???
>
> --- Chris Stephens <[EMAIL PROTECTED]> wrote:
> > Also, the CURRENT OF locks the table so that no one can modify (or
> &g
>> Also, the CURRENT OF locks the table so that no one can modify (or
>> even read) it while the transaction is taking place. This guarantees
>> nothing is changing between retrieving values from the cursor and
>> updating the table based on those values.
Actually, it is the FOR UPDATE that loc
Repeat after me...readers never block writers...writers never block readers...
The update will lock the row(s) of the result set, but it will not block anyone from
reading the data. However, they may not read the modifications made by the update
until it is committed.
MaryAnn Atkinson wrote:
>
--- Kevin Toepke <[EMAIL PROTECTED]> wrote:
> Yes, using WHERE CURRENT OF is faster. It is the same as saying
> "WHERE rowid = emprec.rowid", just more readable. And accesses by
> rowid are faster than index accesses.
>
> Also, what happens if you don't have a unique or primary constraint
> on the
--- Chris Stephens <[EMAIL PROTECTED]> wrote:
> Also, the CURRENT OF locks the table so that no one can modify (or
> even read) it while the transaction is taking place. This guarantees
> nothing is changing between retrieving values from the cursor and
> updating the table based on those value
Yes, using WHERE CURRENT OF is faster. It is the same as saying "WHERE rowid
= emprec.rowid", just more readable. And accesses by rowid are faster than
index accesses.
Also, what happens if you don't have a unique or primary constraint on the
table and whole rows can be duplicated? Then you pretty
I believe
(I could be totally wrong here) the reason for the CURRENT OF is both for
performance and consistency.
The second example has to run the update statement seperately. CURRENT
OF can go directly to the row(s) affected. CURRENT OF still has to modify
each block header in the ta
10 matches
Mail list logo
