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