Hi

Can someone explain the reasoning behind not reconnecting when an ODBC error code of ‘08003’ or ‘08S01’ is received back in modules/db_unixodbc/dbase.c?

Such as on lines 120 and 121?

/* Connection broken */

if( !strncmp((char*)sqlstate,"08003",5) ||

!strncmp((char*)sqlstate,"08S01",5) ) {

ret = reconnect(_h);

if( !SQL_SUCCEEDED(ret) ) return ret;

} else {

return ret;

}

Those error codes equate to Communication link failure and Connection not open both of which are easily handled by a reconnect?

As that logic is used in a few places in dbase.c I figure there must be a reason to exclude those errors from a reconnect, but permit other non-connection related errors to trigger a reconnect?  If the intent was to only allow connection based error codes to attempt a reconnect then wouldn’t it make more sense to explicitly define the half dozen or so ODBC connection specific error codes  (the 08xxx range denotes connection related errors) and only permit the ones which could be repaired by a reconnect?

08001 Client unable to establish connection - Can be caused by transient network issue, so a reconnect attempt is valid

08002 Connection name in use - Reconnect probably wouldnt help here

08003 Connection not open - Reconnect would reopen connection

08004 Server rejected the connection - Can be caused by transient network issue such as a reboot, so a reconnect attempt is valid

08007 Connection failure during transaction  - Can be caused by transient network issue, so a reconnect attempt is valid

08S01 Communication link failure - Can be caused by transient network issue, so a reconnect attempt is valid

ODBC Error code definitions: https://msdn.microsoft.com/en-us/library/ms714687%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396

Of those 6 possible connection related errors only 08002 wouldn’t be helped by a reconnect although a new connection could replace the one its attempting to use…