> BUT, this is not how it used to be!
> Like you mentioned, when the SQL changes, it should
> automatically be doing an unprepare.

> Also, I now know this works, but the unprepare is
> costly (it has a noticable delay) Also, with it setup
> like this, I get flickering with the controls, as though
> it has ignored the DisableControls....

I dont think DisableControls applies to unprepare. IBO
native components do not have persistent columns. When an
unprepare is done the parameter columns disappear - so the
attached controls MUST remove any references that they had
to old columns.

> Other suggestions, if any??

Not really - I cannot envisage how this could possibly have
worked differently before.

Actually, after checking the code in more detail, a change
to SQLWhere should result in an unprepare (although it is
a bit convoluted, so I could be mistaken). This does not
seem to be happening in your code, so we need to find out
why.

Can you try stepping through the code from
TIB_Dataset.SetSQLSelection to see what is actually happening?

AFAICT the line in that method "SQL.Text := NewText;" should
take you through to TIB_Strings.OnChange which should (for
the TIB_Statement.FSQL property) and end up calling
TIB_Statement.OnSQLChange and this should end up calling
unprepare if the statement was prepared.

Various complications arise, especially in queries, because
there can be multiple statements involved (depending on the
specific options in the query). Is there any chance that you
changed the "FetchWholeRows" property or changed the way that
they keys are specified?


(You dont happen to have a backup from last week where you
could run BeyondCompare to find all changes?)

--
Geoff Worboys
Telesis Computing