Re: Informix vs. Oracle

On Wed, 20 Aug 1997 18:39:53 GMT, Nils.Myklebust@idg.no (Nils Myklebust) wrote: >ennis@ssax.com (Bill Ennis) wrote: > >:What about update cursors in Oracle? Oracle will lock EVERY row >:associated with an update cursor when the cursor is opened! Informix >:will lock the row when it fetches. In this case Infomrix is better >:for transaction independency. > >Such behaviour would have been a total showstopper for us. >Do you (or anyone else) know if Oracle have "hold" cursors (cursors >that are keept open accross a transaction)? >In case they do are all rows locked when the cursor is opened in this >case as well? >If that is the case what happen to these locks when a transaction is >committed? > >The Informix solution in this area is very good. > A statement in the form: Select ... from Table where .. for update; will get the update lock on every row before the first fetch occurrs in Oracle this is true. This is typically not an issue. How many rows do you normally fetch with a SELECT ... FOR UPDATE statement? It is also true that the row(s) affected by the select ... for update is open for read by any other transaction (you just cannot select for update those rows that are locked by the above, nor can you update any of those rows). As with any read/write environment in Oracle, you can always READ the data, without a dirty read, even data that is "locked". Yes, regular cursors may be held open across commits. a SELECT ... FOR UPDATE cursor may not be. > >Nils.Myklebust@idg.no >NM Data AS, P.O.Box 9090 Gronland, N-0133 Oslo, Norway >My opinions are those of my company >The Informix FAQ is at http://www.iiug.org Thomas Kyte tkyte@us.oracle.com Oracle Government Bethesda MD http://govt.us.oracle.com/ -- downloadable utilities ---------------------------------------------------------------------------- Opinions are mine and do not necessarily reflect those of Oracle Corporation