> > >
> > > memory on the client is not such an issue - depends on the size of
> each
> > row.
> > > a million ID integers is not the same as a million rows of 350
> > varchar(128)
> > > fields.....
> > > anyway - my concern would be the server RAM. the server needs to
> buffer up
> > > those records and hand them over to the client.
> >
> > But the server will flush them to disk if needed.
> >
> > And given that Firebird has no bi-directional cursors, this does seem
> > a client problem.
> >
> > > either way it's something to be avoided - best practice... keep your
> > > resultsets short and snappy
> >
>
> Yes I agree in keeping them short....
>
> But we have a procedure, that will select around 280.000 records (some
> varchar, some integer, some numeric etc).
> The program will iterate through them, and insert 1 new record for
> each of them.
>
> WITHOUT unidirectional I get a OUT OF MEMORY.
>
> WITH unidirectional I do not get this.
>
> At this point, I have to come up with a solution that will work NOW.
> I have to rewrite to code at some time, to make it better.
>
> So thats the reason......
>
> Michael

you could still manage the selectio of these 280000 records in a far more
efficient manner then just select *.
one way is paging thru them with first skip syntax.
another is to use a master child relation to walk thru a hierarchy of
master/child/child relations which makes the bottom child result sets small.
The overall performance will be significantly improved for both client AND
server
Alan