是这样子的，上个星期，公司的系统出错（都是修改了资料的时候，进行保存，然后出错的，图片不知道怎么发上来，如果需要的话，可以找我要，我的QQ是：315562107）
，根据提示是说更新表有问题，然后我跟踪了一下程序出错执行的语句，和没有出错执行的语句，发现两个的差别是，出错的时候，没有提交事务，事务进行了回滚，但是整个MSSQL语句是没有问题的。
出错的之后，如果退出程序，再登录，再重新操作，这样子重复三四次之后，又可以保存了。还有个问题就是，如果一旦出现错误，不管操作其他什么功能，反正是保存资料都会提示出错，真是头疼啊，都搞了两个星期了，一点问题都没查得出来，差点要血崩了~
，根据提示是说更新表有问题，然后我跟踪了一下程序出错执行的语句，和没有出错执行的语句，发现两个的差别是，出错的时候，没有提交事务，事务进行了回滚，但是整个MSSQL语句是没有问题的。
出错的之后，如果退出程序，再登录，再重新操作，这样子重复三四次之后，又可以保存了。还有个问题就是，如果一旦出现错误，不管操作其他什么功能，反正是保存资料都会提示出错，真是头疼啊，都搞了两个星期了，一点问题都没查得出来，差点要血崩了~
程序是用dephi开发的，但是同样的程序，我用回9月8号的数据库，却不会出错啊，所以一直都是在数据库里面找问题
事务回滚的那一句什么都没判断，只判断了一下，有事务就回滚，IF @@TRANCOUNT > 0 ROLLBACK TRAN，搞不懂程序为什么要回滚事务而不提交。而且提示的是更新表出错。
没有出错的时候，事务都是提交的。
其中,更新表时,数据类型不对而出错的几率较大.
你想,DBMS 会自动把前台送过来的 IF @@TRANCOUNT > 0 COMMIT TRAN 改成 IF @@TRANCOUNT > 0 ROLLBACK TRAN 吗?
用 dbcc readerrorlog 查看过错误日志了，但是无发现有咩问题
什么意思？我跟踪到SQL的代码是有使用到隔离级别，有个Read commit 和 read uncommit。这个影响有多大？
解决的办法是：
1.对比数据库（主要是流水表 经常产生新的数据的表等）
2.找到了这些表后 做数据的分析 删除一些可疑的数据 来查找当前数据库中导致程序出错的因素
3.分析这些数据 不能修改程序 那么就禁止数据库产生类似导致程序出错的数据因素
（如约束等）
呃。。你的想法和我现在的想法是一样，现在也是在做这样子的测试，但是数据库里面的表的关联比较复杂，这样子做，比较花时间，我现在是后台直接delete一些表的数据，不知道这样子能否可行。
检查是什么样的数据可能会产生回滚(还是不相信数据库会有什么问题,如果有问题,以前的数据都无法插入)如果能找到,在表中加一个instead of触发器,看看是否有用.
你可以做这样的测试:不用你的那个系统,而直接在数据库中进行处理.首先看看9月9号有些什么数据,再估计一下程序调用用的什么样的插入语句,然后用类似的插入语句在SSMS里直接插入,如果能插入,那就是程序的问题,如果同样会出问题,那就是数据库的问题.
不过，这种系统架构似乎应当退出历史舞台了。
反汇编还没试过，公司没有dephi的开发人员，所以现在都是把目标放到数据库上。
这个很早就试过了，跟踪出来的语句，在查询分析器里面执行是没有问题的，程序现在是因为回滚了事务，所以提示更新表错误（我现在觉得这个update表错误的提示，并不是语法上的错误，而是业务上的错误提示来的因为那张表是保存所有数量的总和的。）。