At 01:04 AM 12-11-02 +0000, you wrote:

>What is the best method to minimize overhead by the server when I want
>to execute a ib_query again, but

>with new parameters (in BeforeOpen event) and <- case 1

>new "where" criteria (in PrepareSQL)? <- case 2



>I've tested that theese works (in the sense that PrepareSQL and
>BeforeOpen events are executed, and the right dataset is returned):
>(Second time here, so the query is still open)
>a) Close; InvalidateSQL
>b) Close; Unprepare;
>c) Unprepare;


>if Active then Refresh else Open


>which is better? a), b) or c)?

b) and c) are not necessary at all. You only call Unprepare yourself in a
case (not related here) where you want to "put a query to sleep" because
you are not using it any more.

Now, I've marked case 1 and case 2. They are entirely different.

In case 1, if the query is prepared, you leave it prepared. All you need
to do is
1- use some event to collect new parameter values from the user and, in
this event, call the Refresh method of the dataset
2- in the dataset's BeforeOpen, test for Prepared, prepare if necessary,
and then assign the new values to the parameters. Just make sure that
there are values available for the parameters at this point, as there
should be if you did step 1 properly

In case 2, identify the event that causes a need to replace the WHERE
clause and use its handler to store the data you will need to reconstruct
the WHERE clause (probably field names and values: it depends on what you
gave the user as a mechanism for changing the WHERE clause).
Still in this event, call the Invalidate method of the dataset.
Then call the Refresh method of the dataset.

This is the case where you need to write a handler for OnPrepareSQL. You
don't do anything like Unprepare or Prepare, etc., simply call
SQLWhereItems.Clear (probably not necessary, see 2 below), then add the new
SQLWhereItems using the data you stored in the user event handler.

Now, if all those pieces are in place, this is what happens:
1- the user event handler's Invalidate call tells IBO "next time this
dataset is accessed, we are changing the rules."
2- When IBO gets the Refresh call, it unprepares the dataset and I'm pretty
certain it also clears SQLWhereItems. It goes to your OnPrepareSQL handler
and loads in the new WHERE criteria. If you haven't supplied data for the
parameters at this point, no matter, as long as IBO can find an assignment
statement in your BeforeOpen handler AND a place to look for the data.
(Just don't supply the values in both places, that's all).

In either case 1 or case 2, always make sure that there are data available
for any parameter assignment you make there.

If you get an AV when the attempt is made to assign values to parameters,
you will know that you overlooked the Prepare, i.e. you went by a route
where the dataset was in an unprepared state and there was no event that
would cause Prepare to be called. Whenever I'm uncertain about that, I
test for Prepared and call it if necessary.

Helen