> > > > 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......
> > >
> > > Why not create a Stored Procedure for this :-)
> > >
> >
> > selecting * for 280000 records in an SP is notmuch better than
> doing it at
> > the client. In an SP, the server will still cache them out to disk again
>
> Well, you do avoid the network traffic and the client side
> caching problem.
>
> > before it starts to walk thru them.
> > It's miles better to keep them in the fdb file and memory only
> - not back
> > out onto disk again.
>
> They don't _have_ to go to disk if Firebird doesn't want to. It depends
> on the current cache fill, the amount of memory available etc ...
>
> Either way, if Firebird didn't want to handle several thousands
> of records,
> it shouldn't have become a database engine ;-)
>
> With regards,
>
> Martijn Tonies

it's all about bottle necks though isn't it?
if you can select only the records you need and that number of records
avoids secondary caching on disk and maybe it even keeps up with the band
width available to it to offload them, then bottlenecks are kept to a
minimum and other users are kept happy because overall performance is
maximised.
On the other hand if you want your database engine to remain bogged down in
I/O instead of getting it to do what it's best at doing (unions hey)... then
go for it.
Alan