Jason;

I put the following of code just before the call to isc_dsql_prepare:

SQLPlan.Text := '';

Unfortunately, this doesn't do any good because the prepare is
preparing FRefinedSQL which is not affected by setting SQLPlan.
Maybe I am putting this in the wrong place. The code now looks like
this:

procedure TIB_BindingCursor.GetPrepare;
var
SaveCW: word;
MonitorText: string;
begin
FNeedPrepare := true;
with IB_Session do
begin
if PstHandle^ = FakePointer then
PstHandle^ := nil;
SysAllocate;
asm fstcw [SaveCW] end;
-->SQLPlan.Text := '';
-->errcode := isc_dsql_prepare( @status,
PtrHandle,
PstHandle,
null_terminated,
PChar( FRefinedSQL ),
IB_Connection.SQLDialect,
CursorFields.PSQLDA );
asm fldcw [SaveCW] end;

> what I recommend you do is go inside IBO's source (let me know
> if you are not comfortably doing this) and alter the code so that

it wipes

> out the SQLPlan prior to preparing the internal cursor that is

causing the

> error.
>
> Jason Wharton
>
>
> > -----Original Message-----
> > From: IBObjects@yahoogroups.com [mailto:IBObjects@yahoogroups.com]

On

> > Behalf Of Stephen Boyd
> > Sent: Thursday, October 20, 2005 8:12 AM
> > To: IBObjects@yahoogroups.com
> > Subject: [IBO] Re: Strange error
> >
> >
> > > Ah! don't put the plan in the SQL property, put it in the

SQLPlan

> > property
> > > (or in the Plan property, if you are using TIBOQuery).
> > >
> >
> > TIBOQuery.Plan is read only. TIBOQuery.SQLPlan is not a design

time

> > property. I admit that I can stuff the plan in there at run time,
> > but if SQL is a design time property shouldn't SQLPlan also?
> >
> > > All that said, you are *still* going to get the exception back

from

> > the
> > > engine if you specify a plan that the engine can't use, i.e.
> > include a
> > > non-existent index, or one that doesn't participate in the
> > construction of
> > > the streams for the query.
> > >
> >
> > I can live with that. If I screw up the plan I expect to get an
> > error. It is more difficult to live with when the component

screws

> > it up though.
> >
> > > Helen
>