At 07:53 PM 3/06/2005 +0000, you wrote:

>Hi,
>
>I have a very strange problem with a moderatly sized application
>that recently has started playing up, we have not changed the
>application but have changed the domain contraoller for the network
>and thus had to demote and promote all the servers connected to
>it...The usual SBS2k3 story. Anyway the problem symptoms first.
>
>The Delphi 7 / IBO app on one page that creates an invoice crashes
>with
>the following error:
>======================================
>ISC ERROR CODE :335544721
>
>ISC ERROR MESSAGE:
>Unable to complete network request to host "SPEC01".
>Error reading data from the connection.
>An existing connection was forcibily closed by the remote host.
>
>STATEMENT:
>TIB_Statement: "<TApplication>.For.
>
>=======================================
>This happens when the table is posted then Commited, im am testing
>to see if its the post or the commit that crashes, The database far
>end is in another factory 20 miles down the road and has been using
>this system for 4 years now via a VPN Connection, without a hitch.
>the same program also
>drives the local database(same structure) where the Alias points
>simply to the local
>network DB server, This local connection never crashes and leads me
>to be belive that the application is not at fault. Also if i post
>any invoices to the site B database whilst actually at site B it
>never crashes either.
>
>Even More information i found today, one of the other client
>machines CAN run the invoicing system fine on site "B", but they are
>using the old interbase 5.5.0.742 drivers and not the Firebird
>1.5.1.4481 client drivers that are running on both servers at sites
>A and B and all clinet machines (I thought till today anyway!!!).
>
>The application has about 180 forms some very very db intensive
>forms but this particular form seems very simple in contrast.
>
>I dont know where to start looking?

It seems that the only reliable variable here is the one offending
form. Check there to make sure the statement object is pointing to the
IB_Connection and not to some inadvertently overlooked hard DatabaseName
string. However, considering that it doesn't affect faster connections,
the cause is most likely in the way timeouts are configured for the VPN server.

It's quite possible that, if there's a long time lag between when the app
does the select and when the user posts something, the client's connection
has simply been timed out by the server.

>is Interbase more forgiving than Firebird 1.5? if so how/why ?

It might or might not be the source of the problem.

(Off topic for the IBO list, btw, so if you need to persevere with
troubleshooting this, use the firebird-support list).

You mentioned "The usual SBS2k3 story". The handling of timeouts was
changed in Fb 1.5. IB6 and Fb 1.0 used a packet-feeding mechanism to keep
a connection alive, which was unreliable. Fb 1.5 uses the KeepAlive
settings of the server. This is fine, and right, provided the KeepAlive is
configured! The network message you got "An existing connection was
forcibly closed by the remote host" indicates that the server terminated
the connection - the classic 10054 socket timeout error.

You don't say what you are using for the VPN but, if it's MS' own terminal
services, you might find this article helpful:

http://www.windowsnetworking.com/articles_tutorials/Terminal-Services-Group-Policy.html

If it's RealVNC or some other third-party VPN software, search Google with
keywords server +2003 +10054 +"keep alive" ---- you get the picture. :-)

Also, don't overlook the possibility that the server is forcibly timing out
the socket because it's at the limit of allowed requests. From hearsay, I
gather the limit is quite low for SBS. If the keepalive timeout is quite
low (I think the default is 30 seconds) the VPN router could be simply
closing a quiet socket to allow another connection in.

Helen