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了。