> I think Helen hit the nail on the head more or less. IB seems
> to create these huge cursors when given unusual select statements.

AFAICT IB does not provide any means of stepping backwards through
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
to implement.

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 apps
> is to keep Select statements simple.

Thats what I thought. But I need to find some better way of
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
server.

Thanks for your help.

Geoff Worboys
Telesis Computing