RE: full usefullness of CURRENT OF ???

2003-07-11 Thread Chris Stephens
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

RE: full usefullness of CURRENT OF ???

2003-07-11 Thread Kevin Toepke
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

RE: full usefullness of CURRENT OF ???

2003-07-11 Thread MaryAnn Atkinson
--- 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 values.

RE: full usefullness of CURRENT OF ???

2003-07-11 Thread MaryAnn Atkinson
--- 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 table

Re: full usefullness of CURRENT OF ???

2003-07-11 Thread Daniel Fink
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:

RE: full usefullness of CURRENT OF ???

2003-07-11 Thread Kevin Toepke
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 locks the

Re: RE: full usefullness of CURRENT OF ???

2003-07-11 Thread rgaffuri
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 even read) it while the transaction is taking place. This guarantees nothing

RE: full usefullness of CURRENT OF ???

2003-07-11 Thread Chris Stephens
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

Re: full usefullness of CURRENT OF ???

2003-07-11 Thread Tanel Poder
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

Re: RE: full usefullness of CURRENT OF ???

2003-07-11 Thread Jared Still
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] Subject: RE: full usefullness of CURRENT OF ??? --- Chris Stephens [EMAIL PROTECTED] wrote: Also, the CURRENT