一个三层系统，有时用得好好的，连接中间层会报灾难性故障！！

使用的是MTS，ADO连数据库
而且是每天差不多在一个时间段内出现这种问题!!
有没有碰过这类问题

解决方案 »

  1.   

    服务器的所有错误都可能引起 灾难性故障一个很小的错也是如此提示，所以没办法指明具体位置你得靠自已了，主要的是发现引发 灾难性故障 的原因，找到你就会吐血了，可能就是一个很小的错没 catch 到...
      

  2.   

    njbudong可能说的有点道理，这个时间段，所有客户主要进行日结！
    但我做了一个最简单的中间层也会有这个情况，所以一直不解为什么，
    提示的信息就：灾难性故障
      

  3.   

    问过不少人，就连Microsoft都问了，还是不清楚！
      

  4.   

    可以肯定，灾难性故障一般是极隐蔽的错误信息，我以往出现灾难故障的时候对数据进行分析都发现了这此问题，一般其他的数据库固有错误都直接报出详细的出错信息，所以你可以跟踪一下，在灾难性故障的下一句SQL，即出错以后，一般在Exception. Seviry等等东东的下一条，预期应该执行或者执行出错的，大概就差不多了。
    祝你成功！
      

  5.   

    ClientDataSet.data：给值的时候很容易出现！
      

  6.   

    我就不信, 
    你到  msn: [email protected] 找我
    我看看
      

  7.   

    同意 comanche(太可怕)
     等待comanche(太可怕)发言！呵呵
      

  8.   

    在中间层用try..except捕捉错误，然后传出来，
    我碰到一次在中间层连服务器时，客户端传入的密码不对也是报灾难性故障
      

  9.   

    方法一、用try..except捕捉错误，将其记录到一文本文件中，然后分析之方法二、用try...finally记录每一步或关键点或怀疑出错地方的数据信息，将其保存在 个文本中，然后分析之方法三、在系统不是很复杂的情况下，单步跟踪一下服务端程序，看一看服务器端出的什么问题。咱公司的系统基本上都是用这种方法排的错。很方便很快捷！
      

  10.   

    看一下。
    我一直被这种问题搞糊涂了，就算是做个N简单的中层间也会有这样的问题！但并不是在每台机上都会出现的你先说明几个问题：No.1:这N个中间层难到是都在用户高峰期才会出现吗？No.2:并不是在每台机子上出现？是同一个服务器的不同客户端出现的吗？我说一下自己的看法：在多层中，有些错误是模棱两可的，比如一个用户的连接(硬件连接)上有了点小问题，也会出现这种问题，而根据你所说的，应该是在用户在用的时间出现的。我想这不应该是代码上的错误，或是某些基本设置或是和硬件有关，具体的情况也不太清楚，我也不敢胡说。
      

  11.   

    这绝对不是用Try ... Except可以扑捉的到的。
      

  12.   

    DCOM常见错误
    1根事务已提交，但事务已终止了操作。遇到一种情况是TCP/IP的IP或子网掩码设错了或有冲突。
    2发生灾难性故障  中间层全局变量未保护，或线程模式不对。
    3至少一个参数未指定或参数类型不对。中间层ADOQuery语句不对。参数未设好类型或缺省值。
    4查询老超时，即使设定了adoConnection的CommandTimeOut>30也不起作用。这是DELPHI原码的一个BUG。请修改ADODB单元，并把过去的DCU删除，用新的PAS编译一个新的DCU。
    5 OLE error 地址.没有指定的UDL文件。
    6 Client调用时出现不是一个自动化对象，是DCOMConnection没有预先设为True;
    7 无效的被呼叫方 参数的in,out类型，或TLB定义的类型与你传入的参数类型不匹配
    8 未找到指定模块 中间层的DLL没安装或DLL文件的位置与注册MTS时的位置不一致。 
      

  13.   

    大虾们,帮看一下吧:
    http://expert.csdn.net/Expert/topic/1950/1950721.xml?temp=.9892084
      

  14.   

    看来只能算是borland的bug了！很难搞定