Question : Adaptive Server Anywhere - Connection was terminated - SQLSTATE = 04501

We have a situation where a program that uses Sybase Adaptive Server Anywhere ODBC will terminate with the following error:
Select error: SQLSTATE = 04501
[Sybase][ODBC Driver](Adaptive Server Anywhere) Connection was terminated

The program will operate fine for a while and then this error will occur. This will happen on one workstation, while other workstations will continue to operate fine. The program can be immediately restarted and the ODBC connection will be made again.

Answer : Adaptive Server Anywhere - Connection was terminated - SQLSTATE = 04501

There are one of three things going on here:
1) you have a bad fatal error in a operation or stored procedure that is causing the connection to dump.
2) you have some kind of a networking problem at your site.
3) you have a bug in the application code that is either closing the connection or, alternatively, leaving it in a state that causes the next command to blow it up.

In theory, issue 1 should never occur but then there is reality.  I know of at least two commands in ASE that will drop the connection as a byproduct of normal operation.  To hunt this down, start having users keep track of what they were doing just prior to the failure and see if it can be recreated.  Then you can go trolling through the code.

Issue 2 requires calling in your network guys to troubleshoot.  It could be a flakey network card in your server, a bad switch port, or (and I have seen this before) another machine/device with a conflicting network address.  This may in fact be happening to a lot of things like windows mounted disks or printers but they tend to retry and/or auto reconnection where the database connection will give up.

Issue 3 could be just a simple bug in the client code.  If your application does some kind of connection pooling, I would look there first.  I have also seen more than one application where somebody decided it would be a good idea to connect and disconnect around every command sent to the database.  Obviously a really really bad idea.  In my experience, best engineering practices for typical client-server applications makes two connections; one for reading data and the other through which all updates are funneled.  A true model-view-controller application (and most bend the rules) can get buy with one.

Regards,
Bill