> Agreed - mostly I was answering the query raised by what
> Helen was saying.

Understood. I thought as much, and the advice was very good anyway,
so please don't think I have ignored your details!!

>
> Is this code happening from within another event, if so
> what event?

No, this code is placed under an action item, which is tied to a
button & menu item.

> > It's the ELSE section that was working until today, and
> > is now causing AV's
>
> What changed? Not meaning to state the obvious (well maybe
> I am :-) but if it was working and now is not, then something
> must have changed.

I agree! Something must have changed, but I haven't changed any of
this code until today, when I started trying to solve these new
problems.

The other changes are that I am now using FB1.5 as of about a week
ago. Also I updated IBO to 4.2I about 2 weeks ago.
Since these changes, I'm pretty sure the problem code was still
working as expected. I honestly don't think it was either of these,
so it must be something in my code.

You see, the mentioned code is on 5 similar forms I have. They
worked as expected when I set these items up about a month ago, but
as of today all of them have the same problem.

> > if (currentView = vwCurrent) then
> > qry.ParamByName('rp_id').AsInteger := posHISTORY;
> > else begin
> > qry.DisableControls;
> > qry.SQLWhere.Clear;
> > qry.SQLWhere.Add('WHERE Q.RP_ID = :rp_id');
> > if not qry.Prepared then
> > qry.Prepare; <== This is never called...
>
> This is what makes me think you are operating from within
> another event, or something that is impacting where we are
> upto in the processing. The statement should not be prepared
> at this point - the SQL has been changed.

This is exactly what I thought, but it doesn't seem to be the case.

> Perhaps you should
> try an explicit unprepare at the top of this block. Not sure
> if SQLWhere is designed to be used while the statement is
> currently prepared.

OK, I tried this, and it now works (but I'm not ahppy with it)
I put the qry.Unprepare below the DisableControls line.

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....

>
> Oh, hang on thats:
> if not ***qryQuote***.Prepared then
> its not the same component! Now I am confused. Care to
> explain?

Yes, it IS the same query.
I just removed the 'Quote' from the code to try to make it more
clear for you but missed that one! Sorry, I now inadvertantly
confused you. There is only one TIB_Query: 'qry'
I have fixed it in the code snippet above.

Other suggestions, if any??

Thanks for sharing some of your time with me Geoff (& Helen!)
I'm having a bad day! I now have a confused Geoff AND a nervous
Helen.
I'm really stirring the guru pot today!!

Rgds,
-Ryan