--- In firebird-support@yahoogroups.com, "Adam" <s3057043@...> wrote:

>
> I don't remember if you told your results of openning it on the
> local machine and leaving it idle?
>
> Adam
>

Once again, thank all of you for your input and help up to this point.

I've finally achieved some level of successful testing. Today I
installed Database Workbench on our production server and ran three
varying length tests duplicating the steps I had used to crash DBW on
my workstation. On the server, I opened DBW, connected to one of our
production DBs, opened an SQL Query window in DBW, ran a simple Select
query, then left the connection idle for 60 min, 90 min, and 140 min.
In each case I was able to come back to DBW and view data immediately.
On my workstation, however, the same tests result in our old friend
"connection forcibly disconnected by the remote host" error.

Now I'm trying to sort out exactly what, if anything, this proves. To
recap, we are running FB v1.5.3.4870.0 on Windows Server 2003 SE SP1,
running in a virtual server hosted by VMWare ESX on a Linux server.
VMWare support declared their installation innocent today. To this
point it doesn't seem to make much difference what sort of connection
an application uses to connect to FB - we have two older apps that use
BDE, but the same thing happens to DBWorkbench when it is remotely
connected. Only connections to Firebird databases are interrupted -
Remote Desktop sessions are not affected at all. Also, the same
machine hosts two other virtual servers that act as our ColdFusion
and GIS servers, and those are not reporting any problems at all. I am
going to try one more test tonight - I am going to open an ODBC
connection from my workstation to one of the FB databases, run an
embedded query, then let it idle for an hour or so and try to
repopulate the resultset.

I suspect I've been hammering too hard for too long on this, and I may
be overlooking an elephant in the room, so to speak. We are at the
point now that we are considering swapping the servers back to the
original config, and rebuilding the new server as a Win 2000 server
instead of 2003. If I don't learn anything new tonight I will test
that particular configuration on a test server tomorrow. That test
will only be partially accurate, as the test machine is not using a
virtual machine setup - just a straight 2000 server.

I am open to pretty much any suggestions at this point!

Thanks again to everyone,
Scott