记一次超长数值精度错误问题
第一天，客户，某券商，周四晚上联系我们，说DBF文件导入对账的数据，后台数据不对了。
经过我们紧急的排查，发现是读取DBF文件的支持类，出现了问题，没有使用BigDecimal类型，而使用了Double类型.
具体为对账的数据：13344000.0000。存入到ORACLE表中变为了,13.34。还是仅是对账数据的问题，后台直接改表，业务继续处理。
当晚发布给客户临时的class文件替换，因为不想第二天的数据处理还有类似问题。
第二天，发布一个hotfix补丁包，客户在测试环境进行升级，并且校验大数值的情况，是否还会有问题。
结果真的有问题了。
下午五点左右，开始接到客户投诉。6点左右，开始联合公司大佬排查（我们在hotfix已经进行了多次验证，各种数值的临界值都跑过了，确认没有问题）。
晚上8点多，大佬们还在紧急排查，我本地的环境多次跑后，发现我这里显示的数值跟客户的不太一样（客户将DBF文件拷贝给我们），顺藤摸瓜，我开启/关闭了PL\SQL中的Number fields to_char选项，这下终于发现问题了，原来PL\SQL软件本身有精度显示的问题。用sqlplus，设置"set numw 20" ,查询一打，嘿！没问题！。
赶紧跟大佬说了下，大佬联系了客户，我记录下了这件奇葩的事情。
本文来自：记一次超长数值精度错误问题-小码农，转载请保留本条链接，感谢！
温馨提示：
本文最后更新于 2021年01月26日，已超过 1,183 天没有更新。若文章内的图片失效（无法正常加载），请留言反馈或直接联系我。
正文到此结束
- 本文标签： oracle number
- 本文链接： https://djc8.cn/archives/recording-an-error-in-the-precision-of-ultralong-number.html
- 版权声明： 本文由小码农原创发布，转载请遵循《署名-非商业性使用-相同方式共享 4.0 国际 (CC BY-NC-SA 4.0)》许可协议授权
热门推荐
相关文章
该篇文章的评论功能已被站长关闭
关于我
小码农
猫的一生在打哈欠中度过
