在IBM iseries AS400上放置drop not not null時的約束問題

Question

請幫助我，我執行

ALTER TABLE MY_TABLE DATA CAPTURE NONE;
ALTER TABLE MY_TABLE ALTER MY_COLUMN DROP NOT NULL; 

但隨后出現以下錯誤：

SQL狀態：57007

廠商代碼：-910

消息：[SQL0910] MY_TABLE對象類型* FILE MY_SCHEMA具有掛起的更改。

原因。 。 。 。 。 ：MY_TABLE對象在承諾控制下進行的掛起更改阻止了此操作。 您可能產生以下情況之一：

• 該應用過程已在承諾控制下對此對象執行了操作。 事務未提交。 現在，應用程序進程正在嘗試使用* NONE的承諾控制級別來更改同一對象。

• 在承諾控制下，其他流程應用程序已對此對象執行了操作。 事務未提交。

• 該應用過程使用不同的承諾定義在承諾控制下對此對象執行了操作。 事務未提交。

• 該應用過程已在承諾控制下對此對象執行了操作。 事務未提交。

在提交或回滾更改之前，您無法更改表。

恢復。 請執行以下任一操作，然后重試該請求：

• 如果您的應用程序進程發出了未提交的操作，請在嘗試對此對象執行任何其他操作之前運行COMMIT或ROLLBACK，或者使用* NONE以外的承諾控制級別從程序中發出語句。

• 如果在該對象上發出未提交操作的應用程序進程不屬於您的應用程序，則該應用程序進程必須執行COMMIT或ROLLBACK。

• 如果應用程序進程使用不同的承諾定義發布了未提交的操作，請對承諾定義發出COMMIT或ROLLBACK。

• 在嘗試對此主題執行ALTER TABLE語句之前，請發出COMMIT或ROLLBACK。

請幫我！！

Answer 1

該條件表明在承諾控制下的先前工作正在等待中； 等待正常的COMMIT或ROLLBACK，或者先前的處理被中斷並且作業已經結束而無法清理提交定義。 在作業日志中可能已經記錄了先前的消息，以告知更多的條件，而不是sqlcode = -910和msg SQL0910可以顯示的信息。 假脫機作業日志將顯示，很可能是先前的msg CPF325E，帶有激活組和邏輯工作單元，其后是帶有原因碼的msg CPF70A6。 如果沒有假脫機的作業日志，並且沒有審查以前記錄的消息，則很難得知來源。 但是，可以選擇使用“使用承諾定義[initions]（WRKCMTDFN）”（具有搜索所有作業的選項），並且如上所述，可以查看日記以了解請求但未提交的事務。

如果不再由中斷的進程發起，則IPL將在SCPF作業日志中運行日志/提交/數據庫恢復階段[為此IPL時間作業在IPL的系統部分完成后將作業日志假脫機； 例如，查看活動的SCPF作業日志無濟於事]，並且消息記錄已記錄到QSYSOPR和/或QHST [對於這兩個問題，除了從IPF的SCPF作業中假脫機的QPJOBLOG之外，請參見DSPLOG QHST]。

如果在IPL之后問題仍然存在，則* ALL的回收存儲（RCLSTG）[可選地省略其他任何內容； 盡管最好不要忽略* DBXREF， 丟失的 DB更改以后可能會在重新創建或以其他方式對先前有錯誤/恢復活動的數據庫文件執行工作時顯示為錯誤-盡管在SELECT（ * ALL）請求，第二個請求可能只是RCLSTG SELECT（* DBXREF）。

注意：過去存在過一些缺陷，即未在承諾控制下執行的工作錯誤地將文件保留在恢復中 ，表明先前的工作是在承諾控制下完成的； 其效果與不同的消息標識符幾乎沒有什么不同，因此，在兩種情況下，文件待處理的工作都可以免受其他更改活動的影響。 允許刪除那些孤立運行的工作之外的中斷工作，例如使用Delete File（DLTF）或DROP TABLE刪除-請求期間記錄的錯誤將被數據庫忽略，但請仔細檢查消息傳遞以了解表明可能的情況。遇到未解決的問題，例如未刪除成員，這意味着無論創建，還原或添加成員，文件替換都將失敗。 只有與服務提供商聯系才能解決這些困難。