Oracle SQL/Dapper无法识别部分JDE儒略日期数值的问题排查

问题场景 #

在.NET环境中使用Dapper查询Oracle数据库时，针对JD Edwards（JDE）中NUMBER(6,0)类型的儒略日期字段WR.WLDRQJ，当传入2024年2月16日对应的儒略日期124047及之后的值时，触发ORA-01722: invalid number错误；但传入2024年2月15日的124046可正常查询。已验证日期转换结果正确，且相同查询在SQL Developer中可正常执行，怀疑是Dapper动态参数绑定问题。

核心解决方案 #

1. 显式指定参数DbType #

Dapper默认会自动推断参数类型，但在Oracle环境下，部分int值可能被错误推断为其他数值类型（如Int64），导致与NUMBER(6,0)字段类型不匹配。添加参数时显式指定DbType.Int32，强制以正确类型绑定：

parameters.Add("DateStart", dateStart, DbType.Int32);
parameters.Add("DateEnd", dateEnd, DbType.Int32);

2. 统一参数命名格式 #

Oracle的ODP.NET驱动不需要参数名带冒号前缀，Dapper会自动适配。修改所有参数的添加逻辑，去掉参数名中的冒号，避免解析冲突：

parameters = new Dapper.DynamicParameters();
parameters.Add("OpStatus", OpStatus);
parameters.Add("WoStatus", WOStatus);
parameters.Add("Plants", plants);
parameters.Add("Depts", departments);
parameters.Add("WorkCenters", workcenters);
parameters.Add("DateStart", dateStart, DbType.Int32);
parameters.Add("DateEnd", dateEnd, DbType.Int32);
parameters.Add("OpCodes", queryParams.OpCodes);
// 其他参数同理去掉冒号前缀

3. 兜底检查其他参数 #

虽然问题定位在DateEnd，但可额外验证所有IN子句的参数集合（如OpStatus、WoStatus），确保集合内元素均为数值类型，避免隐式转换引发的连锁错误。

原因说明 #

Oracle对参数类型匹配的严格性高于SQL Developer，当Dapper自动推断的参数类型与NUMBER(6,0)字段类型不匹配时，会触发隐式转换失败，抛出ORA-01722错误。显式指定DbType.Int32可确保参数以与字段完全匹配的数值类型传递，消除转换冲突。

内容的提问来源于stack exchange，提问作者Alphatrazz