MySQL 无效数字_ORA-01722: 无效数字的解决方法

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