Oracle NUMBER转.NET Decimal溢出的根本原因是NUMBER精度（38位）超过decimal的28–29位有效数字，尤其NUMBER(38,37)等极端类型易触发Arithmetic operation resulted in an overflow错误。
Oracle NUMBER 转 .NET Decimal 为什么会溢出
根本原因不是数据太大，而是 oracle 的 number 类型精度（最多 38 位）远超 .net decimal 的 28–29 位有效数字。当 oracle 返回一个带 30+ 位小数或整数部分超长的 number（比如 number(38,20)），odp.net 在调用 getdecimal() 或 getvalue() 时会触发 arithmetic operation resulted in an overflow —— 错误堆栈里常出现 decimalconv.getdecimal。
绕过 GetValues() 直接按列类型取值
MyReader.GetValues(objCells) 是问题高发点：它内部对每列统一调用 GetValue()，而该方法在遇到超高精度 NUMBER 时默认走 GetDecimal() 分支，不加判断就崩。
实操建议：
- 改用
GetFieldType(i)先查列的 .NET 类型，再针对性调用读取方法 - 对疑似高精度列（如
OracleDbType.Number），优先用GetOracleNumber(i)获取原始OracleNumber对象 - 需要显示时再用
OracleNumber.Value（仍可能溢出），或更安全地转成string：MyReader.GetOracleNumber(i).ToString() - 若业务允许截断精度，可手动 round：用
OracleNumber.Round(5)再取.Value
在 SQL 层提前控制精度，比代码补救更可靠
很多溢出其实没必要到 .NET 层才处理。直接在存储过程或查询中用 ROUND() 或 TO_CHAR() 压缩数值精度，既减少网络传输量，又规避驱动层转换风险。
例如原存储过程返回浮点列 pval：
SELECT ROUND(pval, 6) AS pval FROM hvm_data_dga
或强制转字符串避免任何数值解析：
SELECT TO_CHAR(pval, 'FM99999999999999999999999999999999999999') AS pval_str FROM ...
注意：TO_CHAR 配合足够长的格式掩码能保住全部 38 位，但需确保前端能按字符串渲染（比如 DataGridView 中设 DefaultCellStyle.Format = ""）。
ODP.NET 版本与连接字符串的关键配置
旧版 ODP.NET（尤其是 11g 时代的 Oracle.DataAccess）对高精度 NUMBER 处理极脆弱；新版 Oracle.ManagedDataAccess 改进了这部分逻辑，但仍默认启用严格转换。
关键配置项（加在连接字符串末尾）：
-
DecimalPrecision=true：启用精度检查（默认 true，溢出时抛异常） -
DecimalPrecision=false：禁用检查，GetDecimal()会尝试截断而非报错（慎用，可能丢精度） - 必须升级到
Oracle.ManagedDataAccess >= 19.11，低版本对NUMBER(38)的兼容性差
真正难处理的不是大数本身，而是混合了极高整数位和极高小数位的 NUMBER(38,37) 这类极端类型——它既不能安全转 decimal，也不适合用 double（精度丢失严重），此时唯一稳妥路径是全程走字符串或 OracleNumber。
