Re: Scroll Cursor for Update

In <5upbca$pp7@cssun.mathcs.emory.edu>, johnl@informix.com (Jonathan Leffler) writes: >It isn't likely to go away. I was afraid of that <g>. >If you want to achieve the equivalent effect, then you use a SCROLL CURSOR >which selects just the primary key values (which will identify each row), >and then fetch the actual data using a normal, non-scrolling CURSOR FOR >UPDATE to fetch each row in turn. That's pretty much what I decided to do. I just hoped Informix might do some of the ugly work for me. Since, the primary need for the SCROLL CURSOR is to support interactive user's paging backward through a selection set, I'm planning to just use FOR UPDATE cursors and "rewind" them when the user goes backwards. I would not be to surprised if this ends up being faster than the SCROLL CURSOR in many cases. This also eliminates the problem of keeping the SCROLL CURSOR synchonized after adds and deletes. And finally, SCROLL CURSOR's doesn't really solve problem of supporting the ability to scroll backward beyond the "start" of the selection set. I have code that handles this, but I can see it would be real slow in many cases. Of course, this would all simpler if I could design the application to match SQL's capabilities, but that's not the job. To all that replied, thanks. Steven