Now for some strange reason I thought it was 4 TCP/IP packets worth, but
have never checked. I could do with a packet sniffer. Results from some
other testing I was doing seemed to imply it was different from machine to
machine, but nothing to do with the IB configuration (client or server),
this leads me to believe it may be to do with the TCP/IP stack.

What concerns me about my belief that it is 4 TCP/IP packets is that I can't
see that the high level code in the remote interfaces is going to know how
many low level packets have been produced.

Maybe I'll do some packet sniffing and figure it out.

It would be cool to be able to tweak this per client (unless it is self
governing), as the data usage profile of a batch process vs. user browsing
makes a huge difference to the consumption of records / second. Seeing the
SQL cursor (i.e. waiting for the server to return more records), could be
reduced be tweaking this algorithm.

BTW. everything I state confidently as fact is up for debate when it comes
to InterBase / FB, as I have spent most of my consulting life observing
behaviour in the beast and then trying to work out why it does what it does
:-)

Cheers,

Jason Chapman
JAC2 Consultancy

Training - Development - Consultancy
Delphi, InterBase, Firebird, OOAD, Development lifecycle assistance,
Troubleshooting projects, QA.....
www: When I get round to it....
Mob: (+44) 07966 211 959 (preferred)
Tel: (+44) 01928 751088


""pablosanchezuy"" <pablos@...> wrote in message
news:aicdre+qje2@......

> Jason, thanks for the input. It=B4s clear that records are sent over
> the wire as the client (gds32.dll) requests it.=20
> I thought you could specify the gds32.dll to request "n" records at=20
> a time. It just "fills" its buffers.
> Any ideas how big it that buffer and if there is any parameter to=20
> control it?
> Pablo S=E1nchez
> pablos@...
>