优选程序告一段落

经过证实，发现Socket通信与SQL通信互不干扰。昨天的问题就是说程序运行时间过长影响通信事件的问题今天似乎找到答案了。这个经验应该予以充分汲取。

是这样的，程序计算时间过长往往是计算过程中发生了错误，而我在dbLib这个类库中的错误处理程序基本上采用了catch……try……finally这种处理方式，而且没有加入提示，看不到错误的发生。因为通信部分是多线程的，而且在通信程序中也有catch……try的错误捕获语句，代码类似如下：

catch(Exception e)
   {
    this.OnError(EventArgs.Empty,e.Message);
   }

这样可以看到Exception这个例外是非常通用的，因此当访问数据发生错误的时候，很有可能被这里面的catch捕捉到，于是造成了通信的混乱。因为catch在抓住错误之后，正常的程序执行会被打乱。在将代码改为以下形式之后这个现象就再也没有发生过，当然，这时在计算程序中也找到并更改了很多错误，本身的计算时间也大大缩短了。

catch(SocketException e)
   {
    this.OnError(EventArgs.Empty,e.Message);
   }

今天还发生了一个有趣的事情，就是我需要在一个timer控件的事件中不断访问主数据库以搜索是否有新的命令单，我使用的也是一个通用的数据库连接，也就是这个：

WoodCon=new System.Data.SqlClient.SqlConnection(@ComConString);

结果问题发生了，因为在正常计算时会根据需要访问SQL数据库，使用的也是这个连接，也许发生了冲突，有的时候会出现

WoodCmd.Connection=WoodCon;

执行错误，有的时候执行的结果乱套了，不知道是哪个SQL语句被执行了，得出的结果集显然不对。是否因为共用了一个连接，而恰好在某一个时刻timer事件处理程序和正常的计算程序同时调用了它造成的错误。

如果是这样的，那么说明timer的事件处理程序应该是在另外的线程中执行的？而且和主线程之间没有一个一致性的安全保护？

解决的办法是单独为timer事件处理程序中访问数据的语句单独建立一个连接：

OrderCon=new System.Data.SqlClient.SqlConnection(@ComConString);

问题没有再出现，似乎解决了，是这样吗？目前还不清楚，有待证实。

不管怎样，今天的结果相当令人满意，基本上Fameview信号发出来，计算就完成了。客户的笑容是内在的……