--- In IBObjects@yahoogroups.com, Helen Borrie <helebor@...> wrote:

>
> At 11:45 AM 30/04/2008, you wrote:
>
>
> >I'll have to see if I can get the client to let me use their

machine

> >and try that. But what would it mean if that fixed it? Would I
> >then have to upgrade everyone to FB211 and IBO 4.8? That would

be

> >scary.
>
> I don't think you read those postings very carefully. "Fb211"

refers to the rebuilt client dll that you would distribute to
replace the Fb 2.0 client dll. You would do that if you had a
reason to, which might include using VERY OLD IBO versions that call
isc_dsql_alloc_statement2() rather than isc_dsql_alloc_statement()
to allocate statement handles.

>
> IBO's practice of deferencing statement handles after moving them

into (I think!) the Statements property of the connection got broken
by a change that Vlad did in Fb 2 to reduce the round trips that
were being done by the old client versions. That involved deferring
some steps under some conditions which, as Vlad implemented it (and
as it stayed throughout Fb 2.0.x and 2.1), mean that the original
handle's address needs to be retained for the life of the statement.

>
> So - under some but not all conditions, apparently - IBO's

dereferencing of the handles became potentially unsafe with the Fb
2+ clients. Alex's take on it was that with isc_dsql_alloc_statement
() it's legal, if unusual, for the client application code to
dereference the statement handles. For isc_dsql_alloc_statement2(),
however, which IBO abandoned many years ago, it was never "legit".

>
> So what Vlad has done, for the benefit of users of interfaces that

dereference statement handles as part of their own internal
management of them - which includes other interfaces besides IBO -
is to change the way a V.2 fbclient refers to the statement
handles. IOW, Fb211 reverts the conditions with regard to statement
handles to how it was before Fb2.

>
> The symptom - to the extent it is recognised so far - is that

disconnecting an application causes the detach function to go into a
loop (consuming 100% of CPU) until the client crashes or the server
AVs or both.

>
> Hence my suggestion that you try the Fb211 client to see whether

YOUR problem goes away. It doesn't imply that it's sure to fix your
problem, AT ALL. It's just that swapping the client library on a
couple of affected client machines would be pretty easy to do...

>

No, I understood what you were saying. I took fb211 to mean the
client that's packaged with FB 2.1, but I misspoke and meant to ask
if using it would require an upgrade to IBO 4.7 and FB 2.1 (and not
FB211) as well. Later, I remembered reading that fbclient is
generally intended to be backward compatible with all versions of
Firebird, so it was a stupid question.

> I must say I find it strange that you're using Fb 4.7, though. It

was replaced by 4.8 to deal with a number of implementation faults
in 4.7. I mean, it seems odd to me that you're going into a panic
at the prospect of swapping the fbclient.dll library on affected
client machines yet you apparently haven't been bothered about
hanging onto a potentially faulty program interface for the past 10
months...

Yeah, well, it's the devil I know <g>. I'm not panicked, just
worried about the amount of QA time that would be required if I had
to do such a thing.