At 09:51 AM 29/10/2003 +0000, you wrote:

>Hi all,
>
>Can someone clarify for me;
>
>1. Should the IBOQuery be prepared before accessing the params property but
>after the SQL strings has been set?

Yes. But Prepare is not necessary if you use ParamByName instead of the
Params[] array.

>2. What if the IBOQuery has already been prepared by a previous statement?
>Does it need to be Unprepared before or after the SQL Strings property is
>set?

No, IBO will do the necessary unpreparing once you break the original SQL.

>3. Will calling prepare, unprepare any previous prepare?

No. If Prepare isn't needed it will be ignored. But it's still better
coding practice to call it as
if not Prepared then Prepare;

>4. None of this was required in the BDE version. Why is it needed here?

You are right about the BDE - because it always unprepares a query after
execution, it has to prepare on every execution if you don't call it
yourself. This is costly (it was designed for Paradox, not client/server
databases...) It's actually faster in the BDE to call Prepare explicitly
than to leave it to do it.

IBO keeps a query prepared as long as you don't change the query
specification and you don't call Unprepare. For normal parameterised
queries, this is what you want; for ad hoc queries, where users are
changing the query spec, the object is broken once you break the SQL (as
your code does), so there is effectively no statement to keep
prepared. IBO begins by invalidating the SQL, which causes it to be
unprepared and to need the new statement prepared next time you assign the
parameters.

Now, native IB_Dataset requires an explicit Prepare if you are using
Params[] directly. I don't know for *sure* whether TIBOQuery follows the
TDataset behaviour on this or whether it is using the Params[] array of the
InternalDataset, which is a TIB_Dataset wrapper, at this point. When using
TIBOQuery, I always cover the bases. Jason will no doubt answer you on
this tomorrow.

In Mark's case, it's impossible to tell from the info supplied whether he's
really getting a crash (which is what would be expected from referring to
Params[] on an unprepared query) or he's getting an unhandled exception
from the invalid dd/mm/yyyy date format. The exception he reported occurs
when you throw an invalid date at a Delphi Date function like StrToDate.

For example, using his date format, today's date would cause that exception:
var
MyDate: TDate;

MyDate := StrToDate('29/10/2003');

The fact that he's actually seeing an exception message indicates the
latter, not the former. When an AV occurs, memory is busted and you don't
see Delphi exceptions.

Helen