On Fri, 16 May 2008 12:51:25 -0400, "Tim Young [Elevate Software]"
<timyoung@elevatesoft.com> wrote:

>Michael,
>
><< So in OnRemoteReconnect you set a flag and then have a TTimer check say
>every minute to see if the flag is set. If it is set close the session and
>reopen it. That's pretty kludgey. >>
>
>No, I would recommend what I stated - give the user the option to decide
>what to do.  They are in the best position to tell the application how to
>respond to the situation, and can check with the network administrator as to
>what happened.

In an unstable wireless network this could be maddening to see a
dialog every time the session is broken.

><< Anyway, OnRemoteReconnect is also fired if say on a wireless network the
>connection is temporarily broken. In that case you just want EDB to
>reconnect on its own as the session still exists. How do you distinguish
>distinguish between the two situations? IOW how do you tell if the session
>still exists on the server? >>
>
>There's no way for EDB or any other application to know.  Only a human being
>can tell what happened to the connection, hence why I recommend that you ask
>said human being.

I don't understand your response. When the client tries to connect to
the server and it's session no longer exists, it generates an error
that states this. So the client does know the session no longer exists
because the server told it. Developers should be able to act on this
information to kill the old session and create a new session.

Michael,

<< In an unstable wireless network this could be maddening to see a dialog
every time the session is broken. >>

What do you expect us to do instead ?  All we can do is report that the
connection is broken - how you deal with that is completely up to you.

<< I don't understand your response. When the client tries to connect to the
server and it's session no longer exists, it generates an error that states
this. So the client does know the session no longer exists because the
server told it. Developers should be able to act on this information to kill
the old session and create a new session. >>

Actually, I was referring to a broken connection, not the "session not
exists" issue.

Yes, the client session knows this *after* it tries to reconnect to the
server, not before.   And, the application receives this exception and can
deal with it in any way it deems necessary, such as shutting down the
session from within a global Application.OnException event handler.

I've attached an example application.

1) Compile the application (be sure to change the appropriate database name
and table name settings for your installation) and run it.

2) Click on the Connect button.

3) Bring up the ElevateDB Server interface, and remove the connected
session.

4) In the grid in the application, try moving to the last row.   The
OnReconnect event handler will tell the session to try a reconnect, and if
the session ID is no longer present, then the Application.OnException event
handler will stop the current session and then re-open the table.

--
Tim Young
Elevate Software
www.elevatesoft.com