Subject | Re: [ib-support] Data paging question |
---|---|
Author | Jason Chapman (JAC2) |
Post date | 2002-07-27T09:18:44Z |
Just to clarify,
You open a query and request the first record:
1) The server works out whether it needs to go and get all of the records
now and store the results on the server or whether it can get them as
required.
2) The server _FILLS_ a buffer to be sent over the wire to the client. I
think this is 4 packets (TCP/IP), but don't quote me on that unless it is
correct.
3) These are sent to the client.
4) The gds32.dll (FB's DLL you need to access FB) stores these packets in
memory and makes the data available to the client.
5) Your client SW says fetch each time it wants a new record.
6) When gds32.dll notices that it's buffer is half depleted it makes another
request to the server to top up its buffer.
This mechanism has the advantages of nagle (aggregation of rows meaning less
packets over the wire) and also the "look ahead" buffer means that if you
are reading hte rows sequencially and slowly, you don't have to wait for
requests as there is always a half full (minimum) buffer.
BTW The BDE doesn't always fetch all rows, it does when you go into edit
mode, but if you were just browsing then not alway.
Just re-read, not the answer required for the original question, but
hopefully helpful to someone :-)
HIH
JAC.
You open a query and request the first record:
1) The server works out whether it needs to go and get all of the records
now and store the results on the server or whether it can get them as
required.
2) The server _FILLS_ a buffer to be sent over the wire to the client. I
think this is 4 packets (TCP/IP), but don't quote me on that unless it is
correct.
3) These are sent to the client.
4) The gds32.dll (FB's DLL you need to access FB) stores these packets in
memory and makes the data available to the client.
5) Your client SW says fetch each time it wants a new record.
6) When gds32.dll notices that it's buffer is half depleted it makes another
request to the server to top up its buffer.
This mechanism has the advantages of nagle (aggregation of rows meaning less
packets over the wire) and also the "look ahead" buffer means that if you
are reading hte rows sequencially and slowly, you don't have to wait for
requests as there is always a half full (minimum) buffer.
BTW The BDE doesn't always fetch all rows, it does when you go into edit
mode, but if you were just browsing then not alway.
Just re-read, not the answer required for the original question, but
hopefully helpful to someone :-)
HIH
JAC.
> How many records the server returns depends on the access method: BDEalways
> returns the entire result set, with e.g. IBObjects you have more controlthrough
> the MaxRows property - but you can only limit the count of records fromthe
> start, not from somewhere in the "middle". (Technically the server returnsone
> row for each FETCH command sent by the client, but it depends how and whenyour
> access components issue those FETCHes)clauses
>
> for the "paging" function: With Firebird you can use the FIRST and SKIP
> in Select statements to do that. Excerpt from the FirebirdRefGuide.pdf:Syntax
> for SELECT
> FIRST m returns an output set consisting of m rows, optionally
> SKIPping n rows and returning a set beginning (n+1) rows from the
> ?top? of the set specified by the rest of the SELECT specification. If
> SKIP n is used and the [FIRST m] parameter is omitted, the output set
> returns all rows in the SELECT specification except the ?top? n rows.
> These parameters generally make sense only if applied to a sorted set.
> </quote>
>
> so you could SELECT FIRST 25 SKIP 0... for the first page and
> SELECT FIRST 25 SKIP 25... for the second etc.
>
> IB6.5 has something like this, too - but iirc Borland uses TOP and LIMIT
> keywords for the same purpose and the syntax is somewhat different...
>
> hth,
> fingerman