Brian,

I ran into this bug about three years ago for the first time.
Unfortunately I was at a customers site when it happened and I had no
real chance to debug it.

As you stated it does _ONLY_ occur when working not locally (but I think
you can reproduce it by using a localhost & tcp/ip connection).

Jason added the ForSelect property for avoiding this bug.

In fact I did the following changes and never have seen this bug again:

1. rewriting all StoredProcs to add a suspend even if they're designed
to return a simngle row.
2. Accessing all StoredProcs are designed to return anything (be it a
single record or a whole bunch of them) by TIB_Cursor or TIB_Query with
SELECT .. FROM <stored_proc>
3. Accessing only StoredProcedures that don't return anything by
TIB_StoredProc or TIB_DSQL.
4. NEVER using a TIB_DSQL for anything else than doing INSERT INTO ..,
UPDATE ..., DELETE ... or EXECUTE PROCEDURE statements -
ie. when asking for a count (*) or any other select - use a TIB_Cursor
(when not "publishing" the results on your forms) or a TIB_Query (when
doing so)

I know - this quite a lot of work (depending on your app size) but as
mentioned above: I haven't seen this bug again since then.

HTH

Luc.

P.S.:
If you're subscribed to the mers-interbase-list or the ib-support-list
list you might have a look there; you'll find some more information on
this.


Brian Dunstan schrieb:

>
> Lucas,
>
> this is getting very scary :-(
>
> I think you are right on the money. In the first place I had this problem I
> have a TIB_StoredProc and the SP uses ForNext and Suspend. I set the
> StoredProcForSelect and sure enough the problem went away.
>
> The next place I had this problem the component was a TIB_DSQL. The SP it
> called takes a bunch of parameters but returns nothing. I changed the
> TIB_DSQL to a TIB_StoredProc and called Prepare before executing it the
> first time and that problem went away also. At this point I think I am on a
> roll...
>
> The same error then popped up in a TIB_DSQL that does a select on a view
> that returns a single row.
> I have been off and studied the news groups but not really got any leads, so
> I have used this:
> if Prepared then Unprepare;
> if not prepared then Prepare;
> Sure enough the problem has gone, but I think this is really dirty and am
> worried about what will fail next.
>
> Later in the same program I found what would be next :-(
> I have another TIB_DSQL that does a COUNT(). After the THIRD execution it
> now causes an Access Violation!
>
> Remember, all this code has been tested with a local connection and did
> work.
>
> I suppose my problem is now that I am apparently chasing a IB bug through my
> code and I have no way of predicting where it will crop up next.
>
> Thanks for you help. I feel like I am close to the problem, but no solution
> yet.
>
> Thanks,
>
> Brian