There is a thread about it in the Borland Newsgroups. Karsten Strobel has
actually found where the problem is in the sources. I recommend taking a
look there since it received a warm welcome from Aaron R. who works for
InterBase. Hopefully Karsten will step forward and complete the resolution
of this bug. I actually have a bounty on fixing this bug for over $1,000
USD. Can't remember exactly how much...

Regards,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com

----- Original Message -----
From: "Lucas Franzen" <luc@...>
To: <IBObjects@yahoogroups.com>
Sent: Wednesday, October 31, 2001 8:52 AM
Subject: Re: [IBO] SQLDA missing or incorrect version


>
> 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
>
>
>
___________________________________________________________________________
> IB Objects - direct, complete, custom connectivity to Firebird or
InterBase
> without the need for BDE, ODBC or any other layer.
>
___________________________________________________________________________
> http://www.ibobjects.com - your IBO community resource for Tech Info
papers,
> keyword-searchable FAQ, community code contributions and more !
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>