ORA-01460错误本质是参数绑定类型、长度或精度与目标列不匹配，常见于字符串过长、DateTime精度超限、decimal小数位不符或AnsiString传中文；需显式设置OracleParameter的OracleDbType、Size、Precision/Scale。
ORA-01460 错误本质是参数绑定不匹配
这个错误不是 oracle 服务端真“不支持转换”，而是 odp.net（或旧版 system.data.oracleclient）在准备 sql 语句时，发现你传入的 parameter 类型、长度、精度与目标列定义或 sql 中期望的类型存在**不可自动推断的安全冲突**。常见于 string 过长、datetime 精度超限、decimal 小数位不匹配，或用了 dbtype.ansistring 却传入含中文的字符串。
检查并显式设置 Parameter 的 DbType 和 Size
ODP.NET 默认靠值推断类型，容易出错。必须为每个 OracleParameter 明确指定 OracleDbType（优先）或 DbType，并设 Size / Precision / Scale：
- 字符串：用
OracleDbType.Varchar2，Size必须 ≥ 列定义长度（如数据库是VARCHAR2(50)，则Size = 50；若传入内容可能超长，按实际最大长度设，别用 -1） - 数字：
OracleDbType.Decimal+ 显式Precision和Scale（例如数据库列是NUMBER(10,2)，就设Precision=10,Scale=2） - 日期：用
OracleDbType.Date（不带毫秒），若需毫秒级用OracleDbType.TimeStamp，避免传DateTime.Now直接绑DbType.DateTime - 不要混用
DbType.String和OracleDbType.NVarchar2—— 中文场景统一用后者 +Size
警惕隐式类型转换和 EF Core / Dapper 的封装陷阱
EF Core 6+ 默认用 ODP.NET，但它的 SqlParameter 映射仍可能绕过显式控制；Dapper 更依赖底层驱动行为。此时错误常发生在：
- 实体类字段是
string，但数据库列为CHAR(10)—— Dapper 默认当VARCHAR2绑定，长度不匹配触发 ORA-01460 - EF Core 执行原始 SQL 时未用
new OracleParameter(...)，而用匿名对象传参，导致驱动无法识别精度 - 使用
OracleCommand.BindByName = true后，参数顺序错乱但名字对了，驱动仍可能因类型模糊报此错
解决办法：绕过 ORM 参数自动绑定，手写 OracleParameter 并完整配置，尤其在执行 ExecuteScalar 或存储过程时。
连接字符串和驱动版本影响参数解析逻辑
ODP.NET 的行为在不同版本差异明显：Oracle.ManagedDataAccess 21.x 对 Size 检查更严格，而 19.x 可能容忍部分溢出。同时，连接字符串中以下配置会放大问题：
-
Unicode=True（默认）下，OracleDbType.Varchar2实际按字节计算长度，中文占 3 字节，Size=10最多存 3 个汉字 —— 改用OracleDbType.NVarchar2按字符计长 -
StmtCacheSize=0关闭语句缓存后，每次执行都重新解析绑定，更容易暴露类型不一致 - 混合使用
Oracle.ManagedDataAccess和旧版Oracle.DataAccess（非托管）会导致参数序列化方式不兼容，直接报 ORA-01460
建议统一升级到最新稳定版 Oracle.ManagedDataAccess，禁用非托管驱动，并在连接字符串中显式声明 Unicode=True;Pooling=true;。
最易被忽略的是：即使 SQL 里只用了一个参数，只要其他参数在同一条命令中存在（比如批量 Insert 多行共用同一 OracleCommand），某一行的某个参数类型/长度异常，整批都会失败 —— 调试时别只盯报错那条数据，要扫全量参数配置。
