At 07:23 PM 9/07/2003 +0200, you wrote:

>Hi Helen,
>i see this feature in your response to Yosi e-mail.

Do you mean the comment I made to Luke Tigaris, regarding slow disconnections?

"Do you have any huge selects? on a request to close a cursor, the server
will finish sending all the unfetched rows before closing it. You can fix
this by limiting the potential maximum size of sets via where clauses."

>
>Can i do this with FireBird 1.0.x and if yes how ? And in FireBird 1.5 ?

You can (and should) do it (restrict the size of output sets via WHERE
clauses) with any SQL dbms. It's not a special feature of Firebird.

>Can i control how many rows i want fetch from a query and then when my
>user push a button continue fetching next sets of rows with IBOQuery ?

In some ways, that is a different question. In SQL, you use the WHERE
clause to tell the database engine WHICH rows you want. So, if you do

SELECT * FROM ATABLE

the database engine returns every row in the table. In a table of 10,000
rows you get 10,000 rows. In the raw, that means the server sends a
package of one or more rows across the wire to the client. It keeps the
rest of the rows back on the server. It waits for the client application
(through an API request) to request one or more further rows, until every
row has been fetched across the wire.

Meanwhile, back at the client, the connectivity software (e.g. IBO, IBX,
Jaybird, etc.) takes control of how many rows cross the wire in each
package. IBO has "horizontal dataset refinement", a name Jason gives to
the work the IBO dataset classes perform in order to control the size of
the package.

I was referring to the use of the WHERE clause to limit the overall size of
this waiting set of output rows (and it is also the topic of your question).

"limiting the potential maximum size of sets via where clauses" means using
criteria in your WHERE clause that can be selected by the user. IBO makes
very powerful use of parameters and this is the normal way to limit the
potential maximum size of an active set. So, to get a set of one row, your
SQL specifies

SELECT <columns> FROM ATABLE
WHERE PRIMARYKEY = :primarykey

and your application provides a way for the user to specify that key.

User-initiated searches are not usually so exact. Most usual will be for
the user to enter search criteria and get one or more matching rows.

Native IBO supports a searching mode (dssSearch) that does a lot of the
programming work of accepting and processing the user's search
criteria. If you are using TIBO* for data access, you need to write this
code yourself to a greater degree - design queries with parameters that
accommodate the user's searching requirements, and design a user-input
interface (with selector controls, input fields and event-triggering
controls such as buttons).

Helen