不是,我发现漏执行的之后,就手动的写一条insert 语句,再把漏的这条数据重新插入,这时触发器就会执行,完全没有问题

@百鸟朝凤: 这样能证明不是处理过程的问题？

这样难道不是证明触发器没有问题么？

为了不说的这么含蓄，我想说的是，好多代码单个执行是没有问题的，

执行多了问题就多了，你觉得是微软的问题多点还是你的代码问题多点的可能性更高呢？

题外话，就事论事只能找错误。

虽然如果我来设计的话，一般是不会用这个方法的，容易出问题，比如像你现在这样，

这样的设计对你的代码处理过程的要求是很严格的，主观一点说，80%~90的程序员是容易出问题的。并发处理大部分人没有想得足够多，线程处理很容易出问题的。

考勤系统我也做过，通常没有实时性要求的，延迟一天，甚至十天都不是问题。

退一万步来说，假设真是SQL SERVER的锅，那么你能咋的？

等他一年还是两年出Service pack？

@爱编程的大叔: 你可能没明白我的意思, 假如处理过程出错的话,我手动执行是过不去的.现在的状态是 4000度条数据中会漏掉几条. 我统计的是一个时间段的信息,假如都到最后计算的话,会非常的慢,所以我才采用触发器的形式; 就算是sqlserver的锅,也不一定就我自己遇到了,我就是想看看大家不是不也遇到过这样的问题,怎么避免解决的,给我点思路

@百鸟朝凤: 你可能没有明白我的意思，我的意思是程序出错，是可能你手动执行不出错，但是自动执行就出错的。如果你不理解这个，那我也没有办法了。

而这是可以查出来的，如果你知道怎么确认错误节点的话。

思路，我已经给了，不要用触发器，至于处理会非常的慢，那就想想为啥会非常的慢好了。

@爱编程的大叔: 恩,我明白你的意思了. 先根据楼下说的写日志记录,查看下具体漏是在什么位置出的错误. 我对数据库这块不是特别的熟悉..触发器在执行的时候是开启了新的线程来操作的?如果触发器在第一次没有执行完的时候第二条数据又触发了触发器,两次操作都对同一张表操作,是不是有可能会造成锁表,导致数据插入不进去?

@百鸟朝凤: 是的。楼下也给了解决方案。

数据库肯定是多线程的，要不然怎么服务几百个客户端连接。

至于是不是锁啥的，那还得看你后续的处理做了写什么。

一般没必要有实时性要求的。

一个方法是，让操作人员点击按钮，才导入。这适合说只有一个人负责导入的情况。

另外一个方法是，写个Windows  Service，负责导入数据，转换数据，检验数据等工作。

@爱编程的大叔: 哦哦,, 那像这种大数据处理的情况, 一天打卡4次,有700多人, 统计一个月的考勤信息,要计算上班天数,请假天数,以及各种休假. 我用触发器,想到的优点是 每打一次卡,我就针对这一条数据做一次统计,实际上就是把最后汇总统计的时间分散到平时,查询的时候可以很快的统计出需要的数据; 要是不用触发器的话,就写一个windows服务,每天晚上拿当天的数据,执行统计,是这样吧?还没有别的思路来做这种数据统计计算非常繁杂的思路?

@百鸟朝凤: 4次700多人就大数据了啊？大数据也太简单了点。

我看过一个20多年前写的，用的是很慢的技术，工厂600~700人，逻辑各种复杂，

也只是等到需要统计的时候，让HR按一下统计。

当然那个系统很慢，随随便便优化一下就能有几十倍上百倍的性能提升。

而且像请假、休假这类的数据，HR通常很难及时录入。

除非很像样的公司，几千号上万号员工的，管理很规范的。

考勤实时统计基本不可能，因为上下班数据是需要两条才能构成一个完整的上班逻辑。

所以实时处理，无非只能做点数据清洗，转换，真正的统计，还是需要按一下统计本月考勤按钮这样。

一般10日或者15日统计一下上个月的考勤就够了，有10天足够让HR收集录入各种请假，特殊情况。

以及员工入职，离职等。按一下统计按钮，运行个10分钟或者夸张一点说，10个小时，也没啥。（看你的代码和逻辑能优化到什么程度了）

运行统计的期间又不需要一个人看着。实在不想按统计按钮也行，做个定时器，每个月9日自动统计上个月的数据好了，统计完成后，前端界面才显示可查询。