不能識別錯誤的來源 - 假設：十進制格式衝突

當執行存儲過程DB2（V8），我收到以下錯誤：不能識別錯誤的來源 - 假設：十進制格式衝突

SQL0304N值不能被分配到一個主機變量，因爲該值爲不在主機變量的數據類型範圍內。 SQLSTATE = 22003

我沒有設置任何類型的跟蹤或特定的錯誤處理，並且錯誤只發生在我不允許玩的客戶端驗證環境中，我沒有很多選項，只是分析了我的再次編碼。

這是我目前分析的結果。谷歌沒有太大的幫助...

我的「10頁」過程創建一個數據集上的CURSOR，通過它並計算每個元素的值，以將其插入到表中。

我已經檢查過（希望）所有的變量類型與用於填充它們的數據類型以及目標表的數據類型，我沒有看到任何衝突。

由於有很多十進制數，乘法和加法，我唯一的假設是計算值對於一個已定義的變量來說太大了。任何人都可以證實這將是「正確的錯誤」？如果計算生成的小數點後的位數大於目標變量類型允許的位數（例如，十進制（6,2）中的100000.123），它也適用嗎？

我也試圖找到一種方法來通過客戶端調試db2 pl sql，但我沒有找到任何解決方案。如果您有任何建議...

提前任何線索:)

來源

2012-08-31 David SCHERRER

根據執行SQL的上下文，它可能爲您提供相關行，它可能會向您顯示哪些內容是有趣的數據。這完全是一個數據類型不匹配 - 我們需要看看你在做什麼來弄清楚在哪裏。但是，是的，這可能是您正在執行的計算的結果。另外，在插入/更新/刪除數據時（除非需要批量處理事務大小），遊標幾乎從不是正確的選擇;有可能重新寫入常規的'INSERT'語句（這可能會運行得更快）。 –

我有3個一般建議。首先是使用某種記錄。主張「編寫代碼」的人儘可能提出建議，即每一行代碼應該是發生或將要發生的事情的輸出。我的第二個建議是模塊化「10頁」程序。如果一段代碼需要滾動顯示所有內容，我傾向於丟失概述。第三個建議是驗證你的假設。在計算東西時，你假設你的變量滿足任何標準。事先做好，確實值得。並記錄驗證結果。 –

@ X-Zero和Juergen Hartelt - 感謝您對我的調查提出的意見和幫助！ –

我的回答是我自己非常感謝......

首先，我的最後一個問題=>我沒有找到任何辦法調試db2通過客戶端連接sql（至少使用DB2 V8）。

在我被授權參與我們的集成客戶環境之後，我可以證實我的假設是正確的。計算結果時，接收乘法的變量格式有時太小（十進制（10,2））。

所採用的解決方案是將變量格式更改爲十進制（15,2），並且由於最終插入的值仍然必須是十進制（10,2），我們通過客戶端驗證了以下內容：

1-檢查變量值：

if (myval > 9999999,99) 
then 
    set myval = 9999999,99; 
end if;

=> 「回十進制（10,2）的要求」

2-獲取回在插入十進制（10,2）：此當d太多時，最後一段代碼也解決了這個問題在小數點之後igits。在插入時，這也會導致錯誤

insert into mytable values (
... , 
CAST(myval AS DECIMAL(12 , 2)), 
... 
)

來源

2012-09-06 14:14:29

不能識別錯誤的來源 - 假設：十進制格式衝突

回答

相關問題