Oracle自定义类型新增CHAR属性读取时前导零丢失原因排查

这个前导零丢失的问题和CHAR类型本身的存储逻辑无关，核心问题出在自定义类型后补修改后的元数据映射、隐式转换链路上，具体原因如下：

• 原有字段CSHR_NBR、SPRN_NBR是MDPHEADEROBJ类型最初创建时就定义的内置属性，存储过程编写时就和表字段做了严格的同类型一一映射，赋值全程没有跨类型转换，CHAR类型定长存储的前导零会被完整保留，不会出现读取异常。
• 新增的EMPNBR属性是通过ALTER TYPE ... ADD ATTRIBUTE ... CASCADE追加的，这里存在两个容易踩的坑：
  • 存储过程如果是在追加类型属性之前完成编译、固化了执行计划的，就算后续做了CASCADE级联修改，存储过程内部接收emp_nbr的局部变量、或是对象属性的赋值链路，很可能因为没有触发重新编译，把emp_nbr的类型识别为数值类型，而非实际声明的CHAR类型。Oracle执行CHAR(10)到数值类型的隐式转换时，会自动把字符串内容当成纯数字解析，截断CHAR类型右侧自动补的空格、丢弃所有前导零，最终就会出现带前导零的字符串值被解析成不带前导零的数字的结果。
  • 如果存储过程使用了SELECT ... INTO MDPHEADEROBJ实例的逐属性顺序赋值写法，后追加的属性在对象结构里的位置如果和SELECT列表的列顺序错位，Oracle会把错位的列值错误映射到对应位置的对象属性上，一旦触发字符转数值的隐式转换逻辑，同样会出现前导零丢失的问题。
• 可以明确的是：表字段里实际存储的EMP_NBR值是完整带前导零的，你看到的异常结果是读取链路的类型错配、隐式转换造成的，并不是数据库修改了原始存储的数据。

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