At 09:58 AM 10-11-02 +0100, you wrote:

> > Now, this time, let's move that assignment statement to the BeforeOpen
> > event and do the following in OnPrepareSQL (just for testing purposes):
>
>It does come up empty, no matter where I try to show it. Not even when it's
>beeing displayed right after I reassign Datum in the OnOrderingChanged
>event, which is so far the only place where the reassignment seems to work.
>
>Monitor is always running, it's just that it doesn't tell me too much.

Whaat? the monitor shows you the SQL that is being passed from the client
to the server AND it shows you the parameters. Make sure you always scroll
right down the monitor's display, otherwise you will miss most of the fun. :-)

>In one of your posting you wrote that it is normal that SQL gets unprepared
>upon reordering of the dataset, does this imply that it's also normal that
>the parameter looses its value?

If you have a prepared query and assign a value to the parameter in a WHERE
clause, that is fine - the query will just go and get the new subset of
rows, using whatever ORDER BY clause was applicable before. The query is
not invalidated, because the ordering hasn't changed. You just assign the
new value to the parameter, call Open and you get the rows you ask for.

However, when you change the OrderingItems, the query gets invalidated - a
flag that tells the dataset to unprepare itself (because it is going to get
a different ORDER BY clause). Once the Unprepare happens, the parameters
disappear. They simply do not exist. They will be created in response to
the query's being reprepared (provided the reprepare is successful, of
course!).

This is why the change event of the datetimepicker is the wrong place to
apply the new value to the parameter.

OnPrepareSQL is the right place to tell the query what the SQLWhereItem
will be (although not the value to be assigned to the parameter in the
SQLWhereItem, because the query does not yet have the parameters...). I
asked you to test the SQL statement in this event because I wanted you to
see how the timing of your assignment was important.

After that event fires, the query will be reparsed to include the new ORDER
BY clause and the "new" (i.e. restated) WHERE clause. So place the
assignment for that date parameter in the BeforeOpen handler because, by
the time that event fires, the query is already prepared.

In other words...and where all this was leading to...in IBO, perform data
things in the dataset, not in the controls. In the dataset, timing is
important. Controls - especially plain VCL non-data-aware controls - don't
know anything that is going on in the dataset. By all means use your
datetimepicker to capture a parameter value - but read the control in a
dataset event, and at a time when it is valid to perform the assignment.

btw, when all of this falls into place for you, you will find that it's
nothing like as hard as you make it to be.

Please don't send support questions to my private email address.

Helen