Re: I cant find it or I'm just lazy ?

On Thursday 06 March 2003 19:08, Bruce Momjian wrote:
> Jeroen T. Vermeulen wrote:
> > On Tue, Feb 25, 2003 at 02:04:50PM +0100, Christoph Haller wrote:
> > > Anyway, you may MOVE until 0 instead of FETCH, or use the COUNT()
> > > function on the query to learn about the number of rows to be returned.
> >
> > Hmm...  Wouldn't the reliability of a count() depend on the isolation
> > level?
> >
> > OTOH the problem with MOVE ALL is that not all cursors support backward
> > scrolling, apparently, and there is no clear documentation (or even
> > diagnostics!) to determine whether they do.
>
> 7.4 does document MOVE ALL as going to the end of the cursor.

Great, Bruce is back !
I drop the idea to use cursors for recordset buffering, and I'm using temp
tables. MOVE ALL can solve my first problem, but It can't solve the other
one: How to know if there is transaction in progress ? The final facts were:
For cursor:    Fast, and less memory (concerning that only query plan is stored on server).Against cursor:    I can't
determineif transaction is already in progress, so I do not     know can I COMMIT on cursor close. (Maybe some other of
myrecordset     controls started transactions before) 
For table:    I do not need transactionAgainst table:    More memory, and slower positioning in the buffer(using LIMIT
andOFFSET) 

OK it is slower, but it works !

I must say one more thing I noticed experimenting with cursors:Let's say that we have cursor with 10 rows, if we MOVE
11rows, cursor  
become unusable, because even if we after that MOVE -5, no row can be
fetched. I do not think that this is bug, but at last notice should be raised
with warning that we missed the cursors size. I even find the code that is
working with cursor, and tried to figure out how to fix this, but it is too
much for me. Sorry !

Regards !