1,594
社区成员
发帖
与我相关
我的任务
分享一个三层系统，有时用得好好的，连接中间层会报灾难性故障！！
使用的是MTS，ADO连数据库
而且是每天差不多在一个时间段内出现这种问题!!
有没有碰过这类问题
而且是每天差不多在一个时间段内出现这种问题!!
有没有碰过这类问题
...全文
请发表友善的回复…
发表回复
yousoft2013 2003-07-02
- 打赏
- 举报
看来只能算是borland的bug了！很难搞定
qiume 2003-06-25
- 打赏
- 举报
大虾们,帮看一下吧:
http://expert.csdn.net/Expert/topic/1950/1950721.xml?temp=.9892084
http://expert.csdn.net/Expert/topic/1950/1950721.xml?temp=.9892084
jshejie 2003-06-19
- 打赏
- 举报
引用了无效的指针
yousoft2013 2003-06-03
- 打赏
- 举报
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时的位置不一致。
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时的位置不一致。
ihihonline 2003-05-26
- 打赏
- 举报
这绝对不是用Try ... Except可以扑捉的到的。
ihihonline 2003-05-26
- 打赏
- 举报
看一下。
我一直被这种问题搞糊涂了，就算是做个N简单的中层间也会有这样的问题！但并不是在每台机上都会出现的
你先说明几个问题：No.1:这N个中间层难到是都在用户高峰期才会出现吗？No.2:并不是在每台机子上出现？是同一个服务器的不同客户端出现的吗？
我说一下自己的看法：在多层中，有些错误是模棱两可的，比如一个用户的连接(硬件连接)上有了点小问题，也会出现这种问题，而根据你所说的，应该是在用户在用的时间出现的。我想这不应该是代码上的错误，或是某些基本设置或是和硬件有关，具体的情况也不太清楚，我也不敢胡说。
我一直被这种问题搞糊涂了，就算是做个N简单的中层间也会有这样的问题！但并不是在每台机上都会出现的
你先说明几个问题：No.1:这N个中间层难到是都在用户高峰期才会出现吗？No.2:并不是在每台机子上出现？是同一个服务器的不同客户端出现的吗？
我说一下自己的看法：在多层中，有些错误是模棱两可的，比如一个用户的连接(硬件连接)上有了点小问题，也会出现这种问题，而根据你所说的，应该是在用户在用的时间出现的。我想这不应该是代码上的错误，或是某些基本设置或是和硬件有关，具体的情况也不太清楚，我也不敢胡说。
jtx1226 2003-05-26
- 打赏
- 举报
问题可是能是在一定条件下出现的，你会找到的。
HanJingJingHan 2003-05-26
- 打赏
- 举报
方法一、用try..except捕捉错误，将其记录到一文本文件中，然后分析之
方法二、用try...finally记录每一步或关键点或怀疑出错地方的数据信息，将其保存在 个文本中，然后分析之
方法三、在系统不是很复杂的情况下，单步跟踪一下服务端程序，看一看服务器端出的什么问题。咱公司的系统基本上都是用这种方法排的错。很方便很快捷！
方法二、用try...finally记录每一步或关键点或怀疑出错地方的数据信息，将其保存在 个文本中，然后分析之
方法三、在系统不是很复杂的情况下，单步跟踪一下服务端程序，看一看服务器端出的什么问题。咱公司的系统基本上都是用这种方法排的错。很方便很快捷！
飞天林 2003-05-26
- 打赏
- 举报
在中间层用try..except捕捉错误，然后传出来，
我碰到一次在中间层连服务器时，客户端传入的密码不对也是报灾难性故障
我碰到一次在中间层连服务器时，客户端传入的密码不对也是报灾难性故障
yousoft2013 2003-05-25
- 打赏
- 举报
我一直被这种问题搞糊涂了，就算是做个N简单的中层间也会有这样的问题！但并不是在每台机上都会出现的
yousoft2013 2003-05-25
- 打赏
- 举报
源码是不可能的，中间层分了数据层与逻辑层，总共代码不下25MB，调试完全通过！
hait 2003-05-20
- 打赏
- 举报
同意 comanche(太可怕)
等待comanche(太可怕)发言！呵呵
等待comanche(太可怕)发言！呵呵
comanche 2003-05-20
- 打赏
- 举报
多一句, 我可能要看原码, 我个人认为是你写的有问题
comanche 2003-05-20
- 打赏
- 举报
我就不信,
你到 msn: comanche@yeah.net 找我
我看看
你到 msn: comanche@yeah.net 找我
我看看
888888888888 2003-05-18
- 打赏
- 举报
关注
myling 2003-05-17
- 打赏
- 举报
捕获一下异常看看
virtualmfc 2003-05-17
- 打赏
- 举报
可以肯定，灾难性故障一般是极隐蔽的错误信息，我以往出现灾难故障的时候对数据进行分析都发现了这此问题，一般其他的数据库固有错误都直接报出详细的出错信息，所以你可以跟踪一下，在灾难性故障的下一句SQL，即出错以后，一般在Exception. Seviry等等东东的下一条，预期应该执行或者执行出错的，大概就差不多了。
祝你成功！
祝你成功！
snake_eye 2003-05-17
- 打赏
- 举报
ClientDataSet.data：给值的时候很容易出现！
virtualmfc 2003-05-17
- 打赏
- 举报
TO:阿德，我所见到的灾难性故障使用异常捕捉根本查不到任何有用的信息。
不知你说的异常是指哪方面？
不知你说的异常是指哪方面？
virtualmfc 2003-05-16
- 打赏
- 举报
我也碰到过，去主动问问高手吧。
加载更多回复（8）
