我这边的CQ执行Apply操作的时候SQL数据库经常死锁，现象见附图，现在只能手工处理，出现阻塞就手工取消“正在阻塞”的那个进程就好了，没找到治本的办法，请大家帮忙。
　　我用的是2002.05的版本

[ 本帖最后由 龙卷卷风 于 2007-2-8 14:56 编辑 ]

你做Apply操作的时候是不是需要发信呀？？

发信？你是指发邮件么？我没有设置邮件规则的。
在哪里看有没有发“信”

这种情况我碰到过好多次了，不知道具体是不是跟使用人数多少有关系。我们一个同时访问的库（大概50人－80人）经常会死锁，其他人数少的从来不会。
我们是做如下处理的：
1）根据论坛有人发的优化的那个文档做了优化
2）做了一个自动检查死锁的工具，发现死锁就自动去杀死这个死锁，主要是人去参与太累了。。。

　　我也想到做个工具监听进程，发现有阻塞的就结束它。但有一点考虑，这个监听程序是一发现有阻塞的进程就马上结束呢还是等上一二秒再结束？我怕如果立即结束的话会有问题，呵呵，楼上的是怎么做的，说说看。
　　对了楼上的用的是什么版本？不知新版本会不会有问题，这个应该是CQ的一个BUG。
　　希望最终有治本的方法。
　　PS，那个优化文档有效吗？那个帖子的关键字是什么？我好搜一下　：）

[ 本帖最后由 龙卷卷风 于 2007-2-8 18:01 编辑 ]

问题还没有解决，看样子只能整工具去杀进程了，呵呵。

不知道 楼主最终解决了没有
现在我也遇到了同样的问题
无从下手  不知道该怎么解决

查hook，大部分是由于hook不合理造成的

楼主你是多少人的应用规模？
主要用什么CLIENT来连接CQ库呢？WEB还是GUI CLIENT？
出现死锁的时候，并发用户数有多少？

你的CQ的版本是什么？是2003版本的还是7.0版本的？DBSET是由什么版本建立起来的？

一般这样出现死锁，你应该去查一下你的HOOK

我们公司大概有70多人在使用CQ
CQ的版本是
2002.05.00  都是使用客户端来访问CQ库的
而且是最近一个星期才开始有这样的情况
我检查了hook  最近一个星期基本上没有做修改
下午在听雨的提醒下 查看了和操作有关的hook  也没有发现有什么异常
有没有办法也定位在什么哪一条SQL语句引起的吗？
当发生阻塞的时候，我查看了引起阻塞的人员，询问了一下
也没有做什么特别的操作，说是正在向一些字段输入内容
所以我也想不出有什么别的办法了