回写公式偶尔不能把数据回写上的解决办法

勤哲excel_林工

     经常遇到同一个回写公式，偶尔会不执行，数据回写不过去，从而造成数据错误和混乱。重存这个表单，数据又能回写正确，说明公式设计和数据填写均没有 问题。
经过长时间的分析，总结后主要有下面两个方面的原因

第一种典型情况

A，b两个模版，a回写b模版，b模版有工作流，a回写到b后，数据实际上已经回写上了，但是如果b继续办理下去，那么就把a回写的数据搞没了。原因是b办理的时候只是看到b模版的上一步交办过来的数据，并没有刷新，所以保存后就把回写的内容覆盖掉了。

对这种情况的解决办法就是想办法在b模版办理的时候刷新一下数据，可以用表间公式从新提取数据，也可以把工作流的协同模式设置成会签式。大家可以根据情况解决

勤哲excel_林工

第二种典型的情况就是遇到了SQL Server的死锁

如果回写公式设计得不好，理论上必然会发生死锁，例如，有两个数据表 x 和 y，模板 A 上有两条保存时执行的回写公式，先回写 x 再回写 y，模板 B 上也有两条保存时执行的回写公式，先回写 y 再回写 x，则若A和B同时填报保存，理论上必然会导致死锁。为什么呢？A和B同时保存，A为了更新x，先锁住了x，B为了更新y，先锁住了y，A接下来要更新y，但是y被B锁了，所以要等待B释放（注意所谓“释放”是要等待事务提交的，也就是B把该做的操作---更新y以及x---都做完了才能提交事务），而B也在等待A释放x，A和B都在互相等待对方释放锁，所以谁都不能完成事务并提交，这就是死锁。

死锁的检查：

当两个事务发生死锁的时候，sql server 会让其中的一个等待一会，等到另一个完成了再提交，但是在业务高峰期，等待时间过长，等待的事务就会被牺牲掉，可以通过在sql server 中做跟踪来监控死锁的发生，方法如下：
1）当业务高峰到来的时候，系统管理员在数据库中执行一句sql：
dbcc traceon(1204,3605,-1)
这句会在sql server 日志中把死锁发生的时间以及死锁的语句记录下来。

2）记录一段时间之后，可以执行 dbcc traceoff，停止对死锁的跟踪。
3）找到SQL Server 的日志文件，它们会在<sql server的安装目录>\MSSQL\log 目录下，名为 ERRORLOG 或 ERRORLOG.n
，如下图

4）打开 SQL Server 的错误日志，在其中搜寻死锁的踪迹
如下图所示的日志记录，其中的 Node:1 和 Node:2 就是发生死锁的一对语句