4D v11 SQL Release 4 (11.4) introduced a new database parameter called "Idle Connections Timeout". Because 4D v11 SQL has a fundamentally different client-server communication model, the purpose of this database parameter may not be generally understood. This preference serves a very specific purpose and should be used only for that purpose.

There has been some question as to what the "correct" value is for this timeout or, even worse, what the "recommended" value is. This reflects a lack of understanding about what this parameter does.

4D v11 SQL in Remote mode performs the following 3 connections to the server per global client process (with default port numbers listed):

• The Application server connection over port 19813
• the DB4D server connection over port 19814
• and the SQL server connection over port 19812

The Application server connection performs as in the past. The timeout for this connection is governed by the existing client-server timeout settings in the Database Preferences. This connection handles are 4D "language" code (as opposed to data access code). This connection never goes completely idle so the timeout is most valuable when there is a problem (e.g. the client crashed, server crashed, someone unplugged the network cable, etc.).

The DB4D server connection is fundamentally different. It is a separate, persistent, statefull connection to the server. This mechanism is what allows 4D Server to run pre-emptive threads. That is, the server portion of this connection is a pre-emptive thread. This connection handles *only* data engine requests. The timeout for the DB4D connection is governed by the Idle Connections Timeout database parameter. This connection definitely goes completely idle if there is no data access; there is no "keep-alive".

The SQL server connections are also fundamentally different. These are, in fact, not persistent (created as needed) and are stateless. These connections handle only SQL calls. On the server side the connection handlers are "pooled" and used as needed. They remain active in memory based on the Idle Connections Timeout.

So, as you can see, Idle Connections Timeout applies only to DB4D and SQL connections. Furthermore, since these connections can go completely idle, this database parameter should be used in situations where network hardware/software is actively killing the idle connections. The goal is to set the Idle Connections Timeout to be lower than the lowest timeout on the network. In this way 4D can gracefully close the idle connection rather than having the network ungracefully kill it.

If the connection is killed, the next time there is a DB4D request (e.g. query, order by, load record, etc.) it will fail.

If the connection is closed by 4D, the next time there is a DB4D request it is automatically re-established so as to be transparent to the user.

Hopefully this makes it obvious that there is no "correct" value for this setting except to say the value must make sense for your network.