DB2 嵌入式 C 專案遭遇 SQLCODE -818 時間戳衝突錯誤排查

問題情境

在開發基於 DB2 的嵌入式 C 語言專案時，發生一件詭異的事，拿出來與大家分享。為保持測試資料完整性、開發人員資料一致性，並減輕 DB Server 壓力，決定每兩人共用一個 DB 實例——噩夢由此開始。

每當開發人員 A 編譯好程式開始執行，使用同一 DB 實例的開發人員 B 也開始編譯執行，此時 A 就會報出 SQL0818N A timestamp conflict occurred. 類似錯誤。於是 A 重新預編譯、執行，OK 開始測試；而此時 B 又會報出剛才 A 的錯誤。兩人陷入無限輪迴。

初接觸 DB2，對嵌入式開發原理不熟，以為是 DB2 或客戶端出問題，卸載 Quest Central、重裝 DB2，問題依舊。後來查資料總結，終於找出緣由。下圖說明建立套件（package）的過程。

根本原因分析

SQLCODE -818 表示「時間戳衝突」。在 DB2 嵌入式 SQL 開發中，預編譯會產生兩個關鍵產出：

1. 應用程式原始碼：將 SQL 陳述式轉換為 DB2 執行呼叫。
2. 綁定檔：包含 SQL 陳述式的存取路徑資訊，用於建立資料庫端的套件。

每次預編譯都會產生新的時間戳，寫入應用程式與綁定檔。執行時，DB2 會比對應用程式攜帶的時間戳與資料庫套件中儲存的時間戳。若不一致，拋出 -818 錯誤。

共用 DB 實例時，兩人輪流預編譯會不斷覆寫同一套件的時間戳。A 預編譯後，套件時間戳更新為 A 的版本；A 執行時匹配成功。但 B 隨後預編譯，套件時間戳又變成 B 的版本；A 再執行時，應用程式攜帶的舊時間戳與資料庫新時間戳不符，觸發 -818。雙方陷入「預編譯→執行→對方預編譯→自己報錯」的死循環。

解決方案

1. 各自使用獨立資料庫實例：最徹底的解決，避免套件衝突。
2. 使用不同的綁定檔名稱/套件名稱：預編譯時指定不同的套件名稱（如加入使用者 ID 前綴），使各自套件互不干擾。
3. 協調開發流程：避免同時對同一實例進行預編譯與執行。
4. 使用版本控制管理綁定檔：確保部署至測試環境的綁定檔與應用程式版本一致。

最佳實務建議

• 嵌入式 SQL 專案中，應用程式與套件時間戳必須同步。
• 團隊開發時，建議每位開發者擁有獨立的資料庫 Schema 或實例。
• 自動化建置流程應包含預編譯、綁定、部署步驟，確保版本一致性。
• 遇到 -818 先檢查：是否重新預編譯但未重新綁定？是否多人共用實例導致套件被覆寫？