> First of all, it has nothing to do with BDE or pdoxusrs.net
> People tend to blame BDE for every evil, but it is rarely as bad! :)
> We dont use BDE and still, experience this problem.

No-one blamed BDE for this particular problem. I don't think anyone
else even mentioned it.

"I will preface this advice by noting that there is no BDE version
that is considered stable for connection to any Firebird Server
version. I will have to assume that this BDE issue has nothing to do
with your problem, but obviously that may not be the case, it may well
be your problem."

I was being relatively kind there. It is an aside to the main theory
(both were not the case this time).

>
> This is what didn't help us:
> - reinstalling Win2003 and FB server from scratch;
> - replacing the server network card.
>
> This is still not solved in toto, but here is a list of things
> that helped to reduce the problem to the point where we dont hear
> from the customer anymore about it:
>
> - making client application exit on half-an-hour inactivity;

Probably good from a resource and security perspective anyway.

> - removing possible long-lasting queries from client application;

Definately a good thing from a garbage management perspective.

> - removing possibilities for long-lasting transactions from client
> application;

Again, good for garbage management

> - more efficient and failure resistant transaction management in
> client application;

Not sure what that could mean? Removing autocommit possibly?

> - nightly sweep;

Good for garbage obviously, mind you a nightly backup is probably just
as useful ;)

>
> I suspect this also:
>
> Remote Interface Bugs (excerpt from FB2 release notes)
> SF #1385092 A TCP/IP connection would appear to freeze the
> Superserver if it was disconnected
> abnormally while a large packet, e.g. a BLOB or a large SQL request,
> was being passed across the
> interface.

It doesn't look related to the original posters issue. The problem the
original poster had is that a disconnection seemed to occur if the
connection was idle. The above occurs if a physical disconnection
occurs while the connection is not idle and a large packet is being
sent. May well have been involved in your issue.

>
> I wonder, when that bug was inserted. Was it version 1.5?

The bug report is public (may wrap)

http://sourceforge.net/tracker/index.php?func=detail&aid=1385092&group_id=9028&atid=109028

According to Alex Peshkoff on the above linked exchange, "This very
old bug was a result of wrong initial design of remote listener is SS
and is present since (at least) ib6 up to vulcan. "

As far as your other post, I agree in principle that it would be nice
to know when a bug was introduced, but that can be a lot of work to
determine. How far back should people be testing. FB 1.5? FB 1? IB 6?
earlier? There are also many offshoot projects, experimental builds
and all that.

I am not familiar with the process works with Firebird, but I can tell
you that for software I am involved with, we do not isolate every
version of the software ever released to see whether the problem
occurred unless it is extremely serious. We note the cause, write the
fix and note in our CRM the build that fixes the issue. If it is more
serious, we backport it.

You could for example state that you know an issue occurs with FB
1.5.3 and is resolved with 2.0, but you would not want to imply that
FB 1.0 is immune unless you have tested it.

Adam