|Subject||Re: [ib-support] Memory Useage with Select Procedure|
> I think Helen hit the nail on the head more or less. IB seemsAFAICT IB does not provide any means of stepping backwards through
> to create these huge cursors when given unusual select statements.
such a query, although perhaps positioned updates in FOR UPDATE
selects may require such buffering. Why should IB need to buffer all
this in a readonly query, I thought it left buffering for the client
I dont really expect an answer, I imagine there are probably some
transaction related reasons that I am not aware of. I am just venting
some frustration. I've read about people with Gigabyte sized
databases and did not expect to run across this sort of memory problem
on my measly 380Mb file. I have lots to learn before this system
grows too much further.
> I disagree. Use lots of stored procedures. The way to faster appsThats what I thought. But I need to find some better way of
> is to keep Select statements simple.
implementing it when the result set could be large. I am working on
an idea of using dual statements - taking a page from the way IBO
implements its buffered datasets. I dont want to buffer such results
at the client, but I do want to be able to step through and process
large and possible complicated selects - without blowing up the
Thanks for your help.