Re: Out of memory error on huge resultset

Nic,

if you just concentrate on the cacheing, and moving logic, that will be
more than enough. Once we get that then we can work on when it should be
invoked.

Dave

On Sat, 2002-10-12 at 08:20, Nic Ferrier wrote:
> Aaron Mulder <ammulder(at)alumni(dot)princeton(dot)edu> writes:
>
> > On 12 Oct 2002, Nic Ferrier wrote:
> > > That's a really good point Barry. I never do that so it's not
> > > something I'd considered.
> > >
> > > Isn't a solution to only do the to_cursor translation when the
> > > statement given begins with "SELECT "?
> >
> > Well, there's always the case of "select * from
> > really_small_table; insert into reall_small table; select * from
> > really_big_table;..."
> >
> > In practice, I've used some 100+ statement commands, because we
> > run updates to one or our internal databases in DBVisualizer, and it
> > passes the entire script as one command. On the other hand, those are all
> > updates, but there's nothing preventing you from putting some selects in
> > there.
> >
> > I think it's best to do what Barry mentioned and disable this for
> > statements containing a ; (or at least containing a ; with any non
> > whitespace thereafter). Then just consider whether you want to search for
> > quoted/escaped ;s.
>
> Yes. It's tricky isn't it. Obviously using multiple SQL statements is
> kinda popular. I've always used stored procs.
>
>
> This is certainly more of a can of worms that I first
> thought. However, I'll finish it off and we'll see how messy it is
> then.
>
>
> Nic
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>
>