Subject | Re: [IBO] connection problems with WLAN clients (timeout?) |
---|---|
Author | Helen Borrie |
Post date | 2007-02-20T05:09:21Z |
At 11:03 AM 20/02/2007, you wrote:
not interrupted, then the connection is active.
The "inactivity" that the server reacts to is when a connection stops
responding to a keep-alive query (similar to a ping from the server
to the client). The server uses the local KeepAlive setting to
determine how long to wait until deciding that the connection is
dead. On Windows, if you don't configure this explicitly, it is 2 hours.
line. If it is a WAN connection then your firewall probably has (or
should have) quite an aggressive timeout setting that (usually)
overrules KeepAlive and operates strictly according to data packet traffic.
You might also look further for the cause of the disconnection...you
don't say whether the WLAN is totally under the control of the
organisation running your software. If users connecting across
normal phone lines, rather than dedicated lines, the timeouts might
be occurring at your service provider...
been successfully established. It is a logical property: it doesn't
become false unless (or until) the application calls Disconnect. The
client cannot tell whether the network connection has been broken for
some reason. The first it will know is when a request fails.
then run a little query and return true if an exception occurs. You
can then call Disconnect or ForceDisconnect to reset the connection
component, before attempting to reconnect.
Helen
>Hi,If the application is connected to the database and the connection is
>on some client computers i have an application running (WinXP, D7, IBO
>4.6). It connects to a FB 2.0 database on startup.
>The application then waits for quite a while (maybe 1, 2, 3 hours)
>until a user "logs in" (with a magnetic stripe card).
>At this moment the application becomes "active" and tries to identify
>the user in the DB, does a few actions... continues waiting.
>
>If I understand other post correctly, the connection is terminated by
>the server after 2 hours of inactivity (?).
not interrupted, then the connection is active.
The "inactivity" that the server reacts to is when a connection stops
responding to a keep-alive query (similar to a ping from the server
to the client). The server uses the local KeepAlive setting to
determine how long to wait until deciding that the connection is
dead. On Windows, if you don't configure this explicitly, it is 2 hours.
>When the app tries to execute a query after that, I get the errorThen you can assume that the connection has died, somewhere along the
>message "an established connection has been closed by the remote host"
>("Eine vorhandene Verbindung wurde vom Remotehost geschlossen").
line. If it is a WAN connection then your firewall probably has (or
should have) quite an aggressive timeout setting that (usually)
overrules KeepAlive and operates strictly according to data packet traffic.
You might also look further for the cause of the disconnection...you
don't say whether the WLAN is totally under the control of the
organisation running your software. If users connecting across
normal phone lines, rather than dedicated lines, the timeouts might
be occurring at your service provider...
>The problem I'm trying to solve: How can I get this status BEFORE theThe IB_Connection's Connected status True means that a connection has
>query tries to execute. Looking at the IB_Connection's connected
>status returns TRUE, but executing the query raises this exception.
been successfully established. It is a logical property: it doesn't
become false unless (or until) the application calls Disconnect. The
client cannot tell whether the network connection has been broken for
some reason. The first it will know is when a request fails.
>Does the IB_Connection have some method like "check for validYes: read the property ConnectionWasLost. The IB_Connection will
>connection"?
then run a little query and return true if an exception occurs. You
can then call Disconnect or ForceDisconnect to reset the connection
component, before attempting to reconnect.
Helen