Hi all,

that's the situation: I have a computer that has WLAN connection only in some areas. Unfortunately, it will be on a truck, so there will be network disconnects. My application has to show a message until the connection is up again, and then go ahead with what it was doing before.

The first thing I tried was of course TDBISAMSession.OnRemoteReconnect. It would be a nice place to set a flag that reconnection is running, show a big fat red message, set Continue to true and do that until everything is up again. Then the flag indicates that the application can hide the message.

Unfortunately, that's not how it works. When you set Continue to True, the data session will eventually jump to TDataSession.Reconnect;. And when reconnection is impossible, that thing will throw an exception which is not handled by DBISAM. I hoped that setting Continue to True will leed to an infinite number of tries to reconnect, but dbisamen.pas says otherwise.

Any idea how I can get my application wait for reconnection for as long as it needs, including a relatively fast reconnection (max 1 second would be nice) when the network connection is up again?

Ralf

I think I found a solution. In OnRemoteReconnect, I call Session.Handle.Reconnect. That will throw an exception as long as the server can't be reached (network disconnection, server is stopped or ended), which you can catch. Put that in a while loop until there is no exception, and you are done.

Except for one situation: if you restart the server, .Reconnect will throw an exception because the new server instance does not know the old client connection. It does not make sense for the client to wait any further. So I wrote a TestSessionLogin method which reates a new client session and sets the parameters from the session which throws the OnRemoteReconnect event. If TestSession.Active := True does not throw an exception, then there is a new server running, you can show the user an error message and stop the client application.

I'd be glad to hear an easier solution, or maybe I forgot something. So... any comments?

Ralf,

<< Unfortunately, that's not how it works. When you set Continue to True,
the data session will eventually jump to TDataSession.Reconnect;. And when
reconnection is impossible, that thing will throw an exception which is not
handled by DBISAM. I hoped that setting Continue to True will leed to an
infinite number of tries to reconnect, but dbisamen.pas says otherwise. >>

The general idea is that the reconnection process is a "one and done"
attempt.  However, DBISAM will not kill the current session, and any attempt
to execute the same operation will restart the connection process.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" wrote:

The general idea is that the reconnection process is a "one and done"
attempt.  However, DBISAM will not kill the current session, and any attempt
to execute the same operation will restart the connection process.

That would imply that you write retry code around every db action at the client side. Therefore I prefer my solution Works like a charm.

Ralf,

<< That would imply that you write retry code around every db action at the
client side. Therefore I prefer my solution Works like a charm. >>

Yes, I might consider adding something similar, since there's no real
downside.

--
Tim Young
Elevate Software
www.elevatesoft.com