Re: Cursor Stability Isolation Level

Hi Bill, thanks for this information. I checked the behaviour on Version 5.x. It's the behaviour you described below. And I agree with your words, this is a problem. It looks like isolation level "COMMITTED READ" if you use CURSOR STABILITY outside an explicit transaction. Bye Stefan PS: Additional information. I used an ESQL/C program and set the isolation level before the OPEN CURSOR statement. Bill Ennis wrote: > > Hi, > > I have a question regarding the use of an isolation level of > Cursor Stability and the use of a normal cursor. > > Reading from the Informix Guide to SQL:Tutorial version 7.2 p.7-14 > "When Cursor Stability is in effect, the database server places a lock > on the latest row fetched. It places a shared lock for an ordinary cursor > and a promotable lock for an update cursor. Only one row is locked at a time; > that is, each time the row is fetched, the lock on the previous row is released > (unless the row is updated, in which case the lock holds until the end of the > transaction). Cursor Stability ensures that a row does not change while the > program examines it." > > I have a program that creates a normal cursor (not an update cursor). When > I set an isolation level of Cursor Stability and fetch a row I do NOT > see a shared lock on the fetched row! > > Now if I fetch the row from within a transaction I do see a shared lock > on the row. In the definition given in he manual there is no mention of > a transaction being available at the time of the fetch. Was this just > an oversight? Is the behavior I'm seeing a problem? Judging from the > sentence "Cursor Stability ensures that a row does not change while the > program examines it." I would think it is a problem. > > Thanks, > Bill > > -- > Bill Ennis Voice: 312-474-7516 > SSA Fax: 312-474-7460 > 500 W. Madison email: ennis@ssax.com ennis@accesschicago.net