Hi Team,

I am in dialog with Tim but I was wondering what others may have experienced/resolved.
Every now and then the EDBServer Log shows a 'flood' of these errors that go on for multiple minutes.  Up to 30 minutes once.
They happen every 30 seconds.
At Tim's suggestion I have checked all the Timers in the Apps and none of them are set at 30secs, 30000mS.
The Customer is in Fiji so fault finding is a bit tricky.  They run a LAN with multiple Usrrs, plus RDP Users, plus ThinFinity Users which are effectively RDP type Users.

So, has anybody else come across this and found some other indirect cause for these errors?
I am open to any suggestions att.

Regards & TIA,
Ian

> They happen every 30 seconds.

The default remote ping interval is 30 seconds.  If the server engine gets restarted or is unavailable for a period of time, you will see one of these for each and every client connection that was active until the session is closed or reconnected on the client side.

Hi Terry,
Fair enough but this was just one session.

Ian

Last time I have seen such a behavior it was caused by a faulty network switch.

> Fair enough but this was just one session.

With the use of "flood" in the description of the problem, I assumed that this was a server restart and you seeing a huge number of these.  With it being just a single session, that just shifts where the disconnect was to the client side.  

This isn't a problem with EDB, but just a side effect of how the remote ping works as it simply sends a request to the server to let it know that it's still there.  It doesn't wait for a response and doesn't have any error handling in it so it happily keeps pumping those signals to the server until the session gets closed.

What we do in our app is to create a scheduled background thread that runs approximately every 5 minutes and does a server time query via the connected session synchronized through the main UI thread.  If that fails and indicates that the session is no longer available, we disconnect and reconnect the session.   Any open tables will be closed and fail, but our primary functions use insert and update queries so it doesn't matter if the connection is on a new session ID.   

Terry Swiers wrote:
What we do in our app is to create a scheduled background thread that runs approximately every 5 minutes and does a server time query via the connected session synchronized through the main UI thread.  If that fails and indicates that the session is no longer available, we disconnect and reconnect the session.   Any open tables will be closed and fail, but our primary functions use insert and update queries so it doesn't matter if the connection is on a new session ID.   

Hi Terry,
The core issue is still an occaisional issue.
Care to end some details of your solution??

Regards & TIA,
Ian

That should have read:  Care to send/share some details of your solution??

I use something similar to the following to check specifically for 1107 errors and close the session if it's missing.  You can easily extend this to attempt a reconnect if you want.

procedure ClearSessionNotFound(Session : TEDBSession);
begin
try
if( Session.SessionType <> stRemote) or ( not Session.Connected) then Exit;
Session.GetRemoteDateTime;
except
on E: Exception do begin
 if (E is EEDBError) then begin
 if (EEDBError(E).ErrorCode <> EDB_ERROR_SESSIONNOTFOUND) then Exit;
 Session.Connected := False;
 end;
 end;
end;

end;

Tks Terry.