We have clients using our BDS 2006 application in combination with the DBServer (4.26 Build 3).

The last installation (server running on Windows 7 machine, client on Vista) is encountering numerous problems with the server apparently closing the client connection at random times. Our application then freezes and the client loses some work and loses his cool.

I thought it might be something peculiar to his setup but lately, even on my computer (WinXP Pro, same version of the Server) I will get random "lost connection" error messages from the server. However, if I retry the operation the server connection is re-established.

Is there a log or other way to debug this situation?

Also, is there a later version of the server? I'm logging into my downloads but it shows only 4.26 Build 3; however, elsewhere in the site you talk about 4.29 Build 3. Is this version likely to address this type of problem and, if so, does one need a support plan to go from 4.26 Build 3 to 4.29 Build 3?

Thanks for any info.

Norman

According with your explanation, it might be a parameter in server.

The Windows has a parameter to control the client disconnection after some
time (idle time). This, by default, is set to 15 minutes. Change this to
99999 and see what happens.

IMO, this is not related with DBISAM.

Eduardo

Eduardo:

Is this setting peculiar to Windows 7 and/or Vista or does it exist in XP as well.

I'm embarrassed to admit I don't quite know which setting you're referring to: can this be changed via command line interface or by editing services or is it programmatic? IOW, how do I view/change it?

Thanks for taking the time to post.

Norman

Well, my Windows is in Portuguese then I really don´t know if the menus I am
trying do describe will be correct.

Administrative Tools
Local domain security
Microsoft network server: 15 minutos should be the default.

Eduardo

Norman,

You are using a fairly old version - 4.29 Build 4 is the most recent release.

You do need to be on maintenance to get it - contact Elevate sales for info on renewing maintenance.

The incidents addressed in DBISAM versions are available here :
http://www.elevatesoft.com/incident?category=dbisam

Not sure whether your specific issue is addressed - with the info provided it's unclear what might be causing this. You'd need to make sure you're not being affected by one of the DBISAM inactivity timeouts for example.

There are number of fixes as well as performance improvements in newer versions. There is also a debug version of the dbsrvr that might be useful for additional troubleshooting.

Raul

I believe you're referring to the "Microsoft network server: Amount of idle time required before suspending a session" setting.

However this only applies to file-share access (SMB) access so if you're using file-share for DBISAM then it might help to tweak it.

It should have no impact when using DBSRVR (e.g. TCP sockets).

Are you using the RemotePing option in your sessions - that alone should ensure that no windows timeout should affect your sessions as there is regular traffic.

Raul

Norman,

<< I thought it might be something peculiar to his setup but lately, even on
my computer (WinXP Pro, same version of the Server) I will get random "lost
connection" error messages from the server. However, if I retry the
operation the server connection is re-established.  >>

The server isn't disconnecting sessions randomly, it is doing so according
to the connection timeout setting in the DBISAM Database Server
configuration.  You can modify this by using the Server Administration
Utility.  However, before doing so, read on...

As Raul indicated, you also want to make sure that you enable the
TDBISAMSession.RemotePing setting in your application's remote session that
is accessing the DBISAM Database Server.  This will tell the remote session
to ping the server every 60 seconds in order to inform the server that the
session is "still there" and to keep the connection open.

Once you enable remote pinging in your application, you should then use the
Server Administration Utility to change the Dead Session Expiration time,
and to bump it down to 30-60 seconds.   That will ensure that any dead
sessions (pinging stopped, so the session/application is gone) are removed
in a reasonable few minutes (last ping time + server connection timeout +
dead session expiration time).

--
Tim Young
Elevate Software
www.elevatesoft.com

Thanks to all who responded.

Tim: I actually did quite a bit of research on Dead Session Expiration, Connection Timeout, RemotePinging, etc. and thought I had a fair grasp of the interrelationships. The logical PROBLEM I had was that I thought the session was supposed to be reconnected seamlessly when a subsequent request was made. That is, if I had read that when the connection times out you've got problems and it won't be automatically reconnected then I would have set up RemotePinging, Dead Session Expiration, Timeout, etc. to ensure the connection was kept alive. But I couldn't understand why there was no reconnection (I hadn't run into this problem with any of my other installations).

So I had to choose my battles: I re-upped for support (really a bargain when you think about it) and gave the site in question the newest version of the DB Server. I also, as a test (and because there are really only two users who use the application, and sporadically at that) set the Connection Timeout to 5 Hours. I know this would be crazy normally but, as I say, these guys never log out and they are the ONLY users. So I wanted to see if issues remained. The jury's still out on that one.

I appreciate the advice to set up Remote Pinging as a "keep alive" and we'll undoubtedly do that, I just am curious why we are having this problem with the session not reconnecting (BTW I set up a trap in the OnConnectionTimeout handler of the Session object but it never fired).

Again, thanks all for taking the time to help me out. Rest assured I'll be pestering Tim if the problem persists.


Norman

"Tim Young [Elevate Software]" wrote:

Norman,

The server isn't disconnecting sessions randomly, it is doing so according
to the connection timeout setting in the DBISAM Database Server
configuration.  You can modify this by using the Server Administration
Utility.  However, before doing so, read on...
-snip-
--
Tim Young
Elevate Software
www.elevatesoft.com

Norman,

<< Tim: I actually did quite a bit of research on Dead Session Expiration,
Connection Timeout, RemotePinging, etc. and thought I had a fair grasp of
the interrelationships. The logical PROBLEM I had was that I thought the
session was supposed to be reconnected seamlessly when a subsequent request
was made. >>

It will, provided that:

1) The session is still present on the DBISAM Database Server.
2) If you have an OnRemoteReconnect event handler, you set the Continue
parameter to True.

Are you saying that neither of these situations is True, and you still can't
reconnect automatically ?

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" wrote:

It will, provided that:

1) The session is still present on the DBISAM Database Server.
2) If you have an OnRemoteReconnect event handler, you set the Continue
parameter to True.

Are you saying that neither of these situations is True, and you still can't
reconnect automatically ?


Tim: Yes to 1). As to 2), I don't have a handler for that event; as an aside, I did a test and inserted code in that handler a (ShowMessage and Continue := True), waited past the connection timeout and it never trapped.

I understand there are a lot of variables in play here, but my concern is that these are the only guys for which the session won't reconnect, even though when I pop-up the server window the sessions are there (disconnected).

I have given them the 4.29 version and am waiting with bated breath. Of course, even if this does correct the problem (which I will gladly take) it DOESN'T answer the question of why the older build is working fine in my other installations. The only possible factor I can think of is that in this case the server is running on Windows 7 (don't have any other sites where that's the case). But it's easy to blame Windows.

Thanks for the response.


Norman