关于 1608 错误
1608错误是ASE常见的错误之一，通常是网络原因，正如手册上所说：
This error occurs when a client process stops without informing AdaptiveServer and a subsequent attempt by Adaptive Server to send results to this client fails.Error 1608 is usually not serious and may be viewed as notification that a client process no longer exists. Some of the possible reasons a client process can disappear are:
• The client application was killed or ended abnormally
• The client machine was powered off or was restarted
• There is excessive network traffic
• The network has been shut down
然而，事非绝对。
• The client application was killed or ended abnormally
• The client machine was powered off or was restarted
• There is excessive network traffic
• The network has been shut down
然而，事非绝对。
我曾经碰到过一个应用总是产生1608错误。许多人认为是网络状况不佳。我并不认同，但这个1608似乎并没有其它影响，于是便没有管它（俺又不是 DBA，关俺什么事先）。直到数据库升级到12.5.2+ESD2后，这个1608导致的问题就大了－－无法连接数据库，因为listener消失，这个 时候我才专门来分析。根据以前 TCP/IP应用开发的经验，我可以断定TDS协议在关闭时的交互应该是这样的：
客户端应用 ASE数据库
TDS层请求关闭会话 －－＞ 确认关闭
＜－－
关闭TDS连接 －－＞ 关闭TCP
TDS层请求关闭会话 －－＞ 确认关闭
＜－－
关闭TDS连接 －－＞ 关闭TCP
显然在特定情况下，客户端会导致数据库产生1608错误，即客户端在请求关闭TDS层会话后，在未得到数据库的确认信息之前，就直接关闭了TCP连接。
自12.5.1开始，ASE引入了动态Listener，这显然是为ASE 15作准备。ASE在引入动态Listener的同时，也引入了不少 BUG。可以相信ASE在处理这种特定情况时，考虑不周全，或者说压根就没有想到会有人（应用）不遵从TDS协议，因而存在BUG。既然是ASE的 BUG，但是也不能等SYBASE出补丁，我们也无从向SYBASE提交这个BUG，那么就要找出源头了。这期间受应用的实际行为与开发人员描述的行为不完全一致的影响，走了不少弯路，最后目光锁定在OLEDB上。
查看OLEDB的readme，有一个CR引起了我的注意，如下：
查看OLEDB的readme，有一个CR引起了我的注意，如下：
Version 02.70.0010 (12.5.0/P-EBF10719/02.70.0010)
……
CR 294297: Oledb Provider would close the network socket after TDS_LOGOUT, without waiting for the TDS_DONE acknowledgement from the ASE.
……
CR 294297: Oledb Provider would close the network socket after TDS_LOGOUT, without waiting for the TDS_DONE acknowledgement from the ASE.
呵呵，果然如此。这让我想起了我以前做的网络应用。我写的服务端应用在数据包检查的一个分支（按照通讯协议，客户端传送过来的数据包是不应该进入这个分支 的）上一时疏漏，没有释放信号量。同事在写客户端（C/C++）时，都是按照我们的通讯协议来做的，一直没有问题。直到后来我用VB全部重写客户端时，由 于VB的字符串处理与C/C++不一样，而导致进入了那个通常不可能进入的分支，结果就不用说了。
闲话少说，回到正题。通知开发人员更新OLEDB及MDAC版本后，1608错误消失，数据库也恢复正常。
闲话少说，回到正题。通知开发人员更新OLEDB及MDAC版本后，1608错误消失，数据库也恢复正常。
后记：后来在网上查到了开源的TDS协议的JAVA实现。它在处理这个问题上也是直接关闭连接。
最近在查看ASE 12.5.3 ESD#4的Targeted CR-List时发现这么一条：
CR 369253 Improve ASE’s network infrastructure to prevent an inability to connect to ASE resulting from a hung engine.
看来最终有望在ASE 12.5.3 ESD#4解决这个问题。
再补充：
CR 399320 Make the network listener immune to non fatal errors.
CR 369253 Improve ASE’s network infrastructure to prevent an inability to connect to ASE resulting from a hung engine.
