### Error updating database. Cause: java.sql.SQLSyntaxErrorException: ORA-01722: 无效数字

### The error may involve com.lecar.user.mapper.StationManageMapper.insertStation-Inline

### The error occurred while setting parameters

### SQL: INSERT INTO T_CORP_STATION_INFO (C_CORP_ID,n_station_code,v_station_name,v_station_header,v_station_tel,v_sendsite,n_area_id,v_station_note,n_inputflag,n_mainflag,n_sendflag,n_arrivedflag, n_endflag,n_sendoutflag,n_sendinflag,n_arrivedoutflag,n_arrivedinflag,n_delflag,v_input_user_name,d_input_date) values (?,?,?,?,?,?, ?,?,?,?, ?,?,?,?, ?,?, ?,?,?,?)

### Cause: java.sql.SQLSyntaxErrorException: ORA-01722: 无效数字

; SQL []; ORA-01722: 无效数字

; nested exception is java.sql.SQLSyntaxErrorException: ORA-01722: 无效数字

at org.springframework.jdbc.support.SQLErrorCodeSQLExceptionTranslator.doTranslate(SQLErrorCodeSQLExceptionTranslator.java:242)

at org.springframework.jdbc.support.AbstractFallbackSQLExceptionTranslator.translate(AbstractFallbackSQLExceptionTranslator.java:73)

at org.mybatis.spring.MyBatisExceptionTranslator.translateExceptionIfPossible(MyBatisExceptionTranslator.java:75)

at org.mybatis.spring.SqlSessionTemplate$SqlSessionInterceptor.invoke(SqlSessionTemplate.java:447)

at com.sun.proxy.$Proxy120.insert(Unknown Source)

at org.mybatis.spring.SqlSessionTemplate.insert(SqlSessionTemplate.java:279)

at org.apache.ibatis.binding.MapperMethod.execute(MapperMethod.java:56)

at org.apache.ibatis.binding.MapperProxy.invoke(MapperProxy.java:53)

at com.sun.proxy.$Proxy189.insertStation(Unknown Source)

at com.lecar.user.company.TestStationMapper.insertStation(TestStationMapper.java:69)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:498)

at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)

at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)

at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)

at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)

at org.springframework.test.context.junit4.statements.RunBeforeTestMethodCallbacks.evaluate(RunBeforeTestMethodCallbacks.java:75)

at org.springframework.test.context.junit4.statements.RunAfterTestMethodCallbacks.evaluate(RunAfterTestMethodCallbacks.java:86)

at org.springframework.test.context.junit4.statements.SpringRepeat.evaluate(SpringRepeat.java:84)

at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)

at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:252)

at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:94)

at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)

at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)

at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)

at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)

at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)

at org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61)

at org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:70)

at org.junit.runners.ParentRunner.run(ParentRunner.java:363)

at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:191)

at org.junit.runner.JUnitCore.run(JUnitCore.java:137)

at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)

at com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)

at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)

at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)

Caused by: java.sql.SQLSyntaxErrorException: ORA-01722: 无效数字

at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:450)

at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:399)

at oracle.jdbc.driver.T4C8Oall.processError(T4C8Oall.java:837)

at oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:459)

at oracle.jdbc.driver.T4CTTIfun.doRPC(T4CTTIfun.java:193)

at oracle.jdbc.driver.T4C8Oall.doOALL(T4C8Oall.java:531)

at oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:225)

at oracle.jdbc.driver.T4CPreparedStatement.executeForRows(T4CPreparedStatement.java:1264)

at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1585)

at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3929)

at oracle.jdbc.driver.OraclePreparedStatement.execute(OraclePreparedStatement.java:4118)

at oracle.jdbc.driver.OraclePreparedStatementWrapper.execute(OraclePreparedStatementWrapper.java:4093)

at com.zaxxer.hikari.pool.ProxyPreparedStatement.execute(ProxyPreparedStatement.java:44)

at com.zaxxer.hikari.pool.HikariProxyPreparedStatement.execute(HikariProxyPreparedStatement.java)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:498)

at org.apache.ibatis.logging.jdbc.PreparedStatementLogger.invoke(PreparedStatementLogger.java:59)

at com.sun.proxy.$Proxy191.execute(Unknown Source)

at org.apache.ibatis.executor.statement.PreparedStatementHandler.update(PreparedStatementHandler.java:46)

at org.apache.ibatis.executor.statement.RoutingStatementHandler.update(RoutingStatementHandler.java:74)

at org.apache.ibatis.executor.SimpleExecutor.doUpdate(SimpleExecutor.java:50)

at org.apache.ibatis.executor.BaseExecutor.update(BaseExecutor.java:117)

at org.apache.ibatis.executor.CachingExecutor.update(CachingExecutor.java:76)

at org.apache.ibatis.session.defaults.DefaultSqlSession.update(DefaultSqlSession.java:198)

at org.apache.ibatis.session.defaults.DefaultSqlSession.insert(DefaultSqlSession.java:185)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:498)

at org.mybatis.spring.SqlSessionTemplate$SqlSessionInterceptor.invoke(SqlSessionTemplate.java:434)

... 34 more

解决办法 ：实体类的格式与数据库格式不匹配！

仔细检查会成功的！

场景：PL/SQL开发时，错误“ORA-01722: 无效数字或者ORA-01722: invalid number”的原因分析(二)

PL/SQL开发时，异常“ORA-01722: 无效数字或者ORA-01722: invalid number”的原因分析(二)

我们在写PL/SQL语句时，经常会用到字符串A与数字B的比较，而很多人的做法是直接做比较，殊不知Oracle会隐含地先将字符串A转换为数字，然后再与数字B做比较，这样做之后，就出现隐患了，即当时写程式时，无论怎么测试都不会出现错误，一旦运行一段时间后，系统使用者就会反映“Form程式出现异常或者是Report出现异常”，而异常就是“ORA-01722: 无效数字或者ORA-01722: invalid number”，而开发者在查找原因时，却会感觉莫名其妙，觉得不可能。

其实，原因很简单，就是在写PL/SQL时，书写不规范造成的，即尽量少使用隐含转换。

排除错误方法：可以先从Where语句中查找，检查是否存在数据类型隐含转换的情况，然后在Select语句中，检查是否存在数据类型隐含转换的情况，还要检查所使用的函数如Nvl、Decode等，检查这些函数中所引用的栏位，是否存在数据类型隐含转换的情况。

例子如下：

-- Create table

create table Test

(

ORDER_Num VARCHAR2(8)

);

insert into Test(Order_Num) Values('123456');

insert into Test(Order_Num) Values('123457');

insert into Test(Order_Num) Values('12345-1');

insert into Test(Order_Num) Values('12345-2');

出错的语句：

Select t.Order_Num, Decode(t.Order_Num, 123456, 'a', 'b') From Test t

where t.order_num < 223456;

改正为：

Select t.Order_Num, Decode(t.Order_Num, '123456', 'a', 'b') From Test t

where t.order_num < '223456';

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