在搞基於DB2的嵌入式C語言項目時，出現了一件非常奇怪的事情，拿出來與大家分享。
當時為了保持測試數據的完整性及開發人員的數據的一致性，更是為了減少DBServer的壓力，故而為每兩人做一個DB實例噩夢由此開始。
每當擔當者A編譯好程序，開始運行的之後，使用同一DB實例的擔當者B也開始編譯運行，此時擔當者A就會報出“SQL0818N A timestamp conflict occurred.”之類的錯誤。於是，A開始重新預編譯，運行，ok，開始測試，而此時的B就會報出剛才A報出的錯誤。
當時，由於剛剛接觸DB2，對其嵌入式開發還不太熟悉其原理，我自己還以為是DB2處了問題或者客戶端出了問題，於是，卸載Quest Central,重新安裝DB2。一直沒有解決問題。
後來，通過查找資料，總結，終於找出其緣由。下圖是創建包的過程。
由於只使用了段條目來標識應用程序中的上下文，修改過的源文件和包被緊緊地鏈接在一起，並且必須保證它們總是指向相同的上下文。這是通過在修改過的源文件中嵌入一個一致性標志(token)，也叫“時間戳(timestamp)”，並且在 DB2UDB 內將相同的值存儲在包信息中來實現的。來自應用程序的每一條請求都帶有這種一致性標志，傳入的值要與編目表中的值相比較。如果這兩個值不相同，並且裝入模塊的時間戳與一致性標志不相同，那麼將發生一個“timestamp”錯誤(SQLCODE -818)。
原因就是如上所述，希望對你有用。
