Select Count(t.Wip_No) As Consignvendnewcreateno_Num

From?? Apps.View_Scm_Wip_Po t

Where? 1 = 1

And??? t.Organization_Id = 85

And??? t.Vendor_Site_Id = 31

查詢后報錯：

ORA-01722: 無效數字

修改后正常：

Select Count(t.Wip_No) As Consignvendnewcreateno_Num

From?? Apps.View_Scm_Wip_Po t

Where? 1 = 1

And??? nvl(t.Organization_Id,0) = 85

And??? t.Vendor_Site_Id = 31

如果不加nvl它就解釋不出來

nvl( ) 函數

從兩個表達式返回一個非 null 值。

語法

NVL(eExpression1, eExpression2)

參數

eExpression1, eExpression2

如果 eExpression1 的計算結果為 null 值，則 NVL( ) 返回 eExpression2。如果 eExpression1 的計算結果不是 null 值，則返回 eExpression1。eExpression1 和 eExpression2 可以是任意一種數據類型。如果 eExpression1 與 eExpression2 的結果皆為 null 值，則 NVL( ) 返回 .NULL.。

返回值類型

字符型、日期型、日期時間型、數值型、貨幣型、邏輯型或 null 值

說明

在不支持 null 值或 null 值無關緊要的情況下，可以使用 NVL( ) 來移去計算或操作中的 null 值。

select nvl(a.name,'空得') as name from student a join school b on a.ID=b.ID

注意：兩個參數得類型要匹配

一個查詢 select to_number(c.name) as srvtype, value as typename from sys_code c where c.srvclass=9 --srvclass為字符型

一直工作得很好，但突然一天返回錯誤ORA-01722 invalid number。由于條件srvclass字段是varchar2類型，就想當然地以為是ORACLE的 bug(恰巧上周剛確認了ORACLE的一個查詢bug)，將條件改寫成 c.srvclass='9'后，查詢就又能運行了。

事情雖然過去了，可總覺得有點不對勁。首先ORACLE不可能出現這么簡單的 BUG；其次就算是BUG，返回的錯誤提示也不應該是 invalid number。按理說，即使ORACLE不能自動完成類型轉換而要求寫成 srvclass='9'，那么對srvclass=9這種寫法的錯誤提示也應該是invalid character。但由于直覺作怪，也就沒有深究

正好space6212提出了他對bug解釋的疑問，我就從頭進行檢查，才發現錯誤的根本原因是：ORACLE將where c.srvclass=9解釋為where to_number(c.srvclass)=9

1)以前執行SQL時，ORACLE進行全表掃描，對每行的srvclass都轉換為number型進行比較.以前表中的srvclass的取值只有字符0到9，所以沒有出錯；

2)后來表中加入了新數據，srvclass的取值都是字母串，ORACLE進行全表掃描時，對新行上srvclass的to_number轉換當然就返回ORA-01722 invalid number了。

總結

以上是生活随笔為你收集整理的MySQL 无效数字_ORA-01722: 无效数字的解决方法的全部內容，希望文章能夠幫你解決所遇到的問題。

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