Error -18 still pops up intermittently

[Fredrick Ughimi]

Are you saying the default value of 30 means 30 minutes? Can we trap error -18 to prevent it from crashing the program anytime it comes up?

[cj]

Are you saying the default value of 30 means 30 minutes? Can we trap error -18 to prevent it from crashing the program anytime it comes up?

1) Yes, the documentation says values are in minutes and the default is 30.

2) SQLitening issues an ExiitProcess if an error occurs unless told to return errors.
I use slSetProcessMods("E0") or slSetProcessMods("E1") to return errors and process them.
In the case of errror -18 (a disconnected program ) a  slConnect then slOpen would be reissued before continuing.
Others must have a way to handle errors when Sqlitening is allowed to ExitProcess.
You mentioned your program "crashes".  It is probably being terminated by Sqlitening, right?


I have a llink to  \SqlItening\Doc\SQLitening.Chm on my desktop


slSetProcessMods (rsModChars String)

Sets the process mod flags, modes, and/or values as controlled by the passed ModChars. Some of the mods are global while some are for the open database. No error can occur.


ModChars:

[G]

Today, late afternoon, I just got these disconnect problems.
After looking for some time, I verified that a small problem resulted in these disconnects every day, after the system time reaches18:12:16, (if you have not changed the default timeout value of 30).
It is very easy to solve. Change the declaration for

"Local llLastRealMsgTime as Word"  to  "Local llLastRealMsgTime as Long"  you will find the declaration in ConnectionMain.

a 2 byte word can hold only 65535 seconds since midnight. You will reach this limit every day approx. at 18:12:16.

[Fred Meier]

Yes that is a problem.  Good catch.  I wll post some uptdates soon.

Get version 1.54 here http://www.sqlitening.com/support/index.php?topic=3384.msg17428#msg17428

[Fredrick Ughimi]

Gunter, thanks for the information. I would try it out and see how it goes. I have also noticed that it doesn't get to 30 minutes before it times out.

[Fredrick Ughimi]

Thank you Fred for the updates.

[cj]

Great catch and thanks Fred for the 1.54 update..

12:33:20 - 03:26:07 = 9 hours, 7 minutes, 13 seconds or 32833 seconds until disconnect.

111023 032607 Conn #16977 SK 448
111023 123320 Dcon #16977 Dropped

Note:
I need to modify client programs because the first thing I did was a select statement and
after receiving an error 18, end the program to receive a crash.  Need to add some
logic to not attempt to perform actions on the server when the connection has been lost.
This is not a big thing, but I can see where clients would call if it occurred.

[Fred Meier]

slGetStatus(4) is currently a way to determine if you are still connected to the server.  Will be adding slGetStatus(5) to next release/update which will return the elapsed seconds since the last message was sent to the server.  This could be used, along with a timer or sleep loop, to determine when a client should be disconnected due to inactivity.  A message could then be displayed to user that they have been disconnected and then they could be reconnected if they request it (like when they return from a long lunch).  This along with the ConnectionTimeOut may be a preferred way to control resources at the server. 

[cj]

Thank you, Fred!

Here are some more things to consider:

1) A wireless adapter may connect when you expect a wired connection.
2) The power management property "Allow this computer to turn off this device to save power" might be 
checked on any network adapter and the server will later correctly drop the connection.

This "SQLiteningServer.log" shows the last connection last night was wireless on "192.168.1.6".
The connection was expected on the wired connection "192.168.1.4".

11 1025 024044 Conn #8 SK 440   192.168.1.6  connect 02:40:44 AM
11 1025 043746 Dcon #8 Dropped               dropped 04:37:46 AM

I am unchecking the save power option on all adapters.

A  wireless adapter for connecting to a wireless printer can connect to SQLitening.
How would others configure to not allow a possible connection to SQLitening?

[Fredrick Ughimi]

Hello Fred,

In the interim, I'd like to suggest that instead of error message -18 popping up when a user is disconnected. We can have a message of this nature:

"Your system has been idle for over 30 minutes, so have been disconnected. You can restart the program to continue". Its just a suggestion. By this way the clients would understand that the program is not reporting a bug in ones program.

Best regards,

[Fred Meier]

I will try to develop a different message for the -18 error in the next release.  Of course, if you are handling errors in your own code then you can display any message you want.  You could even re-connect it desired.

[cj]

This connection (over the internet) lasted almost 7 hours.
The connection was wireless.
10-26-11 09:58:32 Conn #25 SK 440   192.168.1.4
10-26-11 16:37:47 Dcon #25 Dropped
The connection to the mapped drive was also lost.  This was NOT a sqlitening issue.
-----------------------------------------------------------------------------------------------------------------
Rebooted client and now testing without a wireless adapter.  Server is rock solid.
111026185751 Conn #29 SK 440 192.168.1.7 

[Rolf Brandt]

7 hours for an internet connection via WLAN is pretty good. I noticed from other applications that WLAN connections often collapse just for a short time (a second or less) and are reestablished.

Also here in Germany internet providers automatically disconnect every 24 hours. The router will handle the reconnect.

In any way your SQLitening Server connection is lost. So Fred's suggestion to automatically reconnect when you receive error -18 might be a very good solution.

Rolf

[cj]

Good information, thank you.
I am doing these tests because many people leave machines on overnight and curiousity.

Wired connection to client dropped in 9h, 39m 57s or 25,797s
10-26-2011  18:57:51  Conn #29 SK 440 
10-27-2011  04:37:48  Dcon #29 Dropped     
Verified the mapped drive from the client to the server remained.

Now testing with router from client 192.168.1.7 to server 192.168.1.2
10-27-11 06:36:04 Conn #30 SK 440 192.168.1.7

[Fred Meier]

Just a reminder of the different ways the server detects/handles a disconnect.  This is displayed in the log following the Dcon entry.

Dcon -- followed by # and the TCP file number and one of the following:
                     Disconnect = Client issued slDisconnect.
                     Dropped    = Client process ended and the client OS correctly notified the server of that event.
                     WentAway   = Client process ended but the client OS did not notify the server of that event.
                     TimeOut    = Client is inactive (no real messages) longer than the ConnectionTimeOut value in the config file.
                     Killed     = Connection was ended via SQLiteningServerAdmin.
                     Error      = Unrecoverable error occurred.