Oracle NUMBER字段在C#中默认映射为decimal，需根据P（总位数）和S（小数位数）选择合适类型：NUMBER(p,0)且p≤9可转int，10≤p≤19用long，s>0保留小数，无定义则用decimal；转换前须判空并校验范围，推荐用OracleNumber或SQL层TRUNC/TO_NUMBER预处理。
Oracle NUMBER字段在C#中默认映射为decimal
直接读取时，OleDbDataReader、OleDbDataAdapter 或 ExecuteScalar 返回的 NUMBER 字段几乎总是 decimal 类型，哪怕数据库里存的是整数（如 NUMBER(5,0)）。这不是bug，是OLE DB驱动对Oracle NUMBER 的统一处理策略——它不区分精度和小数位，一律按高精度十进制返回。
常见错误现象：int id = (int)reader["ID"]; 报 InvalidCastException；或用 Convert.ToInt32(reader["ID"]) 在值超 int.MaxValue 时静默溢出。
- 不要依赖隐式转换：
decimal→int不是隐式转换，必须显式 cast 或调用Convert方法 - 注意 null 值：Oracle 允许
NUMBER为 NULL，C# 中对应DBNull.Value，需先判空再转换 - 避免
int.Parse(reader["ID"].ToString())：若值为NULL或含小数，会抛异常
根据NUMBER(P,S)精度选择合适C#类型
硬转 int 不安全。Oracle NUMBER 定义含两个关键参数：P（总位数）、S（小数位数）。映射应据此判断：
-
NUMBER(p,0)且p ≤ 9→ 可安全转int（范围 ±21.4亿） -
NUMBER(p,0)且10 ≤ p ≤ 19→ 应用long，否则可能溢出 -
NUMBER(p,s)且s > 0→ 必须保留小数，用decimal或double（后者有精度损失） -
NUMBER无显式定义（即NUMBER(38)）→ 默认按decimal处理，不可盲目强转
示例：reader.GetDecimal(0) 拿到值后，用 value % 1 == 0 && value <= int.MaxValue && value >= int.MinValue 判断是否可转 int，比直接 Convert.ToInt32 更可控。
用 OracleNumber 结构做边界防护
当业务字段可能存极大值（如序列号、统计计数），又不想全程用 decimal，可用 OracleNumber（需引用 System.Data.OracleClient，注意该命名空间已过时，但仍在部分老项目中使用）。
OracleNumber 能承载 Oracle 原生 NUMBER 的全量范围（±10²⁷），且提供 .ToInt32()、.ToInt64() 等带溢出检查的方法：
OracleNumber val = reader.GetOracleNumber(0); if (!val.IsNull) { int i = val.ToInt32(); }- 若值超出
int范围，ToInt32()抛OracleException（ORA-22053），比静默截断更可靠 - 注意：仅适用于
OracleClient驱动；OleDb不支持GetOracleNumber，需换用 ODP.NET
批量转换时优先在SQL层做类型归一化
如果大量字段需“整数化”，与其在C#逐个判断转换，不如在查询时用 Oracle 函数提前处理：
- 确定为整数且需转
INT：用TRUNC(col)去小数，再TO_NUMBER(TRUNC(col))确保类型干净 - 避免
TO_CHAR+Parse：如TO_CHAR(col, 'FM999999999')再 C# 解析，性能差且易因格式符出错 - 布尔模拟字段（如
NUMBER(1,0)存 0/1）：直接CASE WHEN col = 1 THEN 'Y' ELSE 'N' END，C#端收字符串更直观
这种做法把类型适配逻辑下沉到数据库层，C#代码更轻、更稳定，也规避了驱动层对 NUMBER 解析的不确定性。
真正麻烦的不是转换本身，而是 NUMBER(P,S) 定义缺失或不一致——比如 DBA 把主键定义成 NUMBER（即 NUMBER(38)），而代码里一直当 int 用，上线后某天插入超限值才暴露。所以，查表结构、确认精度，比写转换逻辑更重要。
