Icon View Thread

The following is the text of the current message along with any replies.
Messages 11 to 16 of 16 total
Thread Connection lost during table upgrade
Mon, Dec 8 2014 10:31 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Martijn


>First I noticed this sentence in the RemoteTimeout documentation: "The server may just simply be executing a very long process and has not sent a progress message in a longer period of time than what is configured for the RemoteTimeout property".
>
>Then I found using the DBISAM code that for table upgrades the server sends these progress messages only if a OnUpgradeProgress event has been set on the client side.
>
>So I added an empty OnUpgradeProgress to my TDBISAMQuery and that fixed the problem. The server is now sending progress back to my client during the lenghty table upgrade which prevents the client from disconnecting due to a timeout (in dbisamen.pas's TDataSession.Receive).

As the manual suggests this may not be a complete fix. I don't know if Tim changed it to work on an interval as ElevateDB does but back when I used DBISAM it reported progress after a percentage of the work has been done. The interval between two updates could be longer than your timeout.

You also have to add a progress event to all queries that might be longer than your timeout. RemotePing needs setting for the session only and then resolves the problem for all queries of whatever nature.

Roy Lambert
Mon, Dec 8 2014 12:38 PMPermanent Link

Martijn Laan

My issue was with the table upgrade timeout, I'm fine with query timeouts (+there's no query progress event I think). But thanks for the heads up.

Also I didn't mention this but I've set ProgressSteps to 100 to ensure low time between steps. Additionally I've tried RemotePing but it didn't help preventing the error (it just delayed it till the upgrade was done).
Mon, Dec 8 2014 12:54 PMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Martijn

>My issue was with the table upgrade timeout, I'm fine with query timeouts (+there's no query progress event I think). But thanks for the heads up.

There is such an event.

>Also I didn't mention this but I've set ProgressSteps to 100 to ensure low time between steps.

That may or may not work. Most likely it will work but there's an outside chance it won't.

>Additionally I've tried RemotePing but it didn't help preventing the error (it just delayed it till the upgrade was done).

In that case I'd guess you're doing something wrong. From my now antiquated manual

<<With pinging turned on, the only reason a session would be disconnected by the
server is if the client workstation or the physical network connection has failed.>>

What did you set the RemotePingInterval to?

Roy Lambert
Tue, Dec 9 2014 3:02 AMPermanent Link

Martijn Laan

<<With pinging turned on, the only reason a session would be disconnected by the
server is if the client workstation or the physical network connection has failed.>>

The issue was the client disconnecting, not the server.
Tue, Dec 9 2014 7:09 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Martijn

><<With pinging turned on, the only reason a session would be disconnected by the
>server is if the client workstation or the physical network connection has failed.>>
>
>The issue was the client disconnecting, not the server.

The following is a bit of a simplification but may enhance your understanding.

You open a connection to the server from the client by opening an appropriately configured session. You close the connection by closing the session. Closing the application closes the session.

The client program simply establishes or breaks a connection. If this is done correctly the connection will rapidly appear/disappear from the list in the server.

If the server detects no activity on the connection for the specified period of time it will then mark that connection as disconnected and leave it sitting there for a while. If some activity takes place between being marked as disconnected and a further specified time the connection will be removed. This allows for someone to not do anything for a bit and then pick up where they left off (sort of).

Lack of activity to / from the server can be caused by the client sitting idle, the server running a lengthy process which prevents any communication, the power going off at the client or the physical network connection being broken. That's it.

The only other reason for the client to disconnect is that the program has closed the session and that will not leave a dead connection on the server. If the client is disconnecting and you don't want it to then the program has to be changed to stop it closing the session.

Roy Lambert
Tue, Dec 9 2014 7:34 AMPermanent Link

Martijn Laan

Roy, I already know why the client was disconnecting, see above. But thanks anyway.
Previous PagePage 2 of 2
Jump to Page:  1 2
Image