Sent: Wednesday, June 11, 2014 12:13 PM

关于同时更新两个database table的方法可以总结成以下三种。详细的测试代码在附件，感兴趣可以看看。

1. 表1在normal的work process里进行update，表2通过update function module进行update。
   n 如果表2更新出错，或者是更新表2的update function module 没有通过COMMIT WORK 触发，就会出现表1成功更新，但表2未更新的inconsistent状态。

2.  表1和表2分别在不同的两个update function module里更新
   

3.  表1和表3的更新放在同一个update function module里更新
   

我用不同颜色标注这三种方法，是因为法2和法3从技术上说两张表要么都成功更新，要么都未更新，不可能出现不一致的状态。
只有方法1可能会出现不一致的状态-----但是很不巧PCM 的代码就采用的法1来更新history table和order table这两张表。

所以yinqiang的这个结论，对于法2和法3来说是绝对正确的，但不适用于法1.

如果单纯从技术上分析为什么status 更新没有成功，标准程序里: release一个order时状态从UNPR改成PROC是在下面的update function module里执行:

通过ST05 trace可以确认:

所以如果status没有更新成功，可能的原因就下面几种:

1.  更改状态的update function module ( line 65 ) 执行失败
   

2. FM CMS_LO_STATUS_PREPARE_UPD_DB 输出的lt_records_to_update 为空，导致update function module 实际上没有执行，因为task队列为空 3. 执行完line 65的FM之后，status 又在其他地方被修改成了UNPR（包括客户自己的enhancement）

系统的逻辑是先在当前session修改history table，然后在update work process （一个新的session里更新header status）:

看callstack能发现header status change是在一个新的update process里:

当系统负载重的时候，可能会导致系统没有空闲的update work process，从而header的status没有机会得到更新:

通过将update function call改成local update的方式，可以排查到底是不是这个问题引起的。

关于yin qiang slide里的这个观点，我个人有不同的观点:

现在蒙牛更新history table是采用online 更新，而header status是采用update task的方式更新，技术上来说如果后者出错，理论上是有可能存在history table已经成功更新，但是header status仍然未更新的情况发生。

可以通过下面的report来模拟: line 14 更新history table，在Function module ZSQFB里更新header status.

执行report即可发现history table成功更新，但header status未更新。

要获取更多Jerry的原创文章，请关注公众号"汪子熙":