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

關于同時更新兩個database table的方法可以總結成以下三種。詳細的測試代碼在附件，感興趣可以看看。

表1在normal的work process里進行update，表2通過update function module進行update。
n 如果表2更新出錯，或者是更新表2的update function module 沒有通過COMMIT WORK 觸發，就會出現表1成功更新，但表2未更新的inconsistent狀態。

表1和表2分別在不同的兩個update function module里更新

表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沒有更新成功，可能的原因就下面幾種:

更改狀態的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的原創文章，請關注公眾號"汪子熙":

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的蒙牛 customer Project Support - 同时更新两个database table的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。