5,888
社区成员
发帖
与我相关
我的任务
分享急：DB2 Decimal update时精度出现问题
我有一张数据库表，表中有字段 aaa decimal(17,2).
在使用过程中出现如下问题：
在给字段赋值433.36后，打日志得到值是433.36。
在数据库update后，打日志得到值为433.35。
中间未做任何处理。
请问有何办法可以避免此类问题？
数据库版本为：DB2 9.5,程序为Proc的程序。
PS：该问题不是经常出现，在更新数据库100次后可能会出现一次。
在使用过程中出现如下问题：
在给字段赋值433.36后，打日志得到值是433.36。
在数据库update后，打日志得到值为433.35。
中间未做任何处理。
请问有何办法可以避免此类问题？
数据库版本为：DB2 9.5,程序为Proc的程序。
PS：该问题不是经常出现，在更新数据库100次后可能会出现一次。
...全文
请发表友善的回复…
发表回复
sTigerwsk 2010-01-01
- 打赏
- 举报
DB2V9.7版本中不再会出现该问题……
据IBM人士解释……
据IBM人士解释……
sTigerwsk 2009-11-16
- 打赏
- 举报
再次研究了一下，发现如果将一个C中的double类型不做四舍五入处理，直接交给数据库，多次更新后会出现精度问题……
今天又出了一个怪问题，0.01直接更新之后变成0了……
今天又出了一个怪问题，0.01直接更新之后变成0了……
sTigerwsk 2009-11-03
- 打赏
- 举报
DB2的对应字段直接建成double型字段？然后设置精度？
leonjava 2009-10-28
- 打赏
- 举报
之前也遇到类似情况
把 DOUBLE 的精度加长 变为3位搞定
把 DOUBLE 的精度加长 变为3位搞定
johdan_honey 2009-10-24
- 打赏
- 举报
建议你把日志打印的数据的精度提高，按照你的情况必然是因为还有第三位小数造成的
ACMAIN_CHM 2009-10-23
- 打赏
- 举报
[Quote]而且见到过db2插值进去后，值会变成一个高精度近似数，比如，2.13,插进去有可能会变成2.1299999999[/Quote]
首先我们先达成共识, 计算机中无法用8或或N个字节表示某个区间内所有的实数 . 而 2.13 你可以试着把它转换成 2进制。
所以在计算中如果有double的小数，会有误差。
但 decimal 本身应该没有， 所以需要看你是如何插入这个小数的，当然也要看你对这个字段的定义是什么？ 是 deciaml(, 还是double 这也是为会要检查你的表结构。
首先我们先达成共识, 计算机中无法用8或或N个字节表示某个区间内所有的实数 . 而 2.13 你可以试着把它转换成 2进制。
所以在计算中如果有double的小数，会有误差。
但 decimal 本身应该没有， 所以需要看你是如何插入这个小数的，当然也要看你对这个字段的定义是什么？ 是 deciaml(, 还是double 这也是为会要检查你的表结构。
sTigerwsk 2009-10-23
- 打赏
- 举报
上面说的那种情况是不指定decimal的精度有可能会出现。
sTigerwsk 2009-10-23
- 打赏
- 举报
[Quote=引用 3 楼 acmain_chm 的回复:]
应该不是BUG，
建议贴出来你的表结构，以及你的插入语句。你的db2版一，这样其它人也可以试一下。
[/Quote]
大哥，这个跟表结构貌似没有关系。我的db2版本是9.5，这个问题在8系统列的版本上也出现过。
类似问题有人在chinaunix也发帖询问了。
而且见到过db2插值进去后，值会变成一个高精度近似数，比如，2.13,插进去有可能会变成2.1299999999
应该不是BUG，
建议贴出来你的表结构，以及你的插入语句。你的db2版一，这样其它人也可以试一下。
[/Quote]
大哥，这个跟表结构貌似没有关系。我的db2版本是9.5，这个问题在8系统列的版本上也出现过。
类似问题有人在chinaunix也发帖询问了。
而且见到过db2插值进去后，值会变成一个高精度近似数，比如，2.13,插进去有可能会变成2.1299999999
sTigerwsk 2009-10-23
- 打赏
- 举报
[Quote=引用 4 楼 mr_bean 的回复:]
数据库一直都有类似问题 但是我碰到的只是存储奇数尾数才会出 现在能缓解方法是decimal转为double
[/Quote]
原来使用oracle数据库，没有发现类似问题，也可能是较少使用奇数尾数。
数据库一直都有类似问题 但是我碰到的只是存储奇数尾数才会出 现在能缓解方法是decimal转为double
[/Quote]
原来使用oracle数据库，没有发现类似问题，也可能是较少使用奇数尾数。
WWWWA 2009-10-23
- 打赏
- 举报
用DOUBLE类型试试，如果没有问题，则是decimal的问题
sTigerwsk 2009-10-23
- 打赏
- 举报
[Quote=引用 2 楼 wwwwa 的回复:]
直接赋值没有经过计算，应该是BUG吧
[/Quote]
有经过一个计算，一个简单的减法计算。
原decimal字段的值是555988.36, 然后减去555555, 得到433.36，此处第一次打日志，打出来的日志为433.36。
然后进行update操作，操作前打日志，433.36，操作后需要查询结果插入别一张表中，查询后打日志,433.35……
且这个问题出现的频率确实不是很高，很偶然的出现……
精度？类型转换？decimal与double的差别？
直接赋值没有经过计算，应该是BUG吧
[/Quote]
有经过一个计算，一个简单的减法计算。
原decimal字段的值是555988.36, 然后减去555555, 得到433.36，此处第一次打日志，打出来的日志为433.36。
然后进行update操作，操作前打日志，433.36，操作后需要查询结果插入别一张表中，查询后打日志,433.35……
且这个问题出现的频率确实不是很高，很偶然的出现……
精度？类型转换？decimal与double的差别？
sTigerwsk 2009-10-23
- 打赏
- 举报
[Quote=引用 3 楼 acmain_chm 的回复:]
应该不是BUG，
建议贴出来你的表结构，以及你的插入语句。你的db2版一，这样其它人也可以试一下。
[/Quote]
这个跟表结构没有什么关系。
我用的是类似于insert into aaa (aa, bb, cc) values(11,22,33);
update时采用的是用游标打开获取当前记录，然后update current cursor的方式去更新。
很怀疑是proc的double与decimal的转换……
应该不是BUG，
建议贴出来你的表结构，以及你的插入语句。你的db2版一，这样其它人也可以试一下。
[/Quote]
这个跟表结构没有什么关系。
我用的是类似于insert into aaa (aa, bb, cc) values(11,22,33);
update时采用的是用游标打开获取当前记录，然后update current cursor的方式去更新。
很怀疑是proc的double与decimal的转换……
sTigerwsk 2009-10-23
- 打赏
- 举报
在proc中连接两次打印出来的值都是对的，然后经过一次update操作后，再从数据库读出来，打日志值就差了0.01.
这个如果说proc的问题也是bd2，proc的问题吧，在oracle下没有遇到过这样的问题。
初步怀疑与decimal的存储方式有关。
这个如果说proc的问题也是bd2，proc的问题吧，在oracle下没有遇到过这样的问题。
初步怀疑与decimal的存储方式有关。
Liyingyue_FFS 2009-10-23
- 打赏
- 举报
[Quote=引用 12 楼 acmain_chm 的回复:]
引用而且见到过db2插值进去后，值会变成一个高精度近似数，比如，2.13,插进去有可能会变成2.1299999999
首先我们先达成共识, 计算机中无法用8或或N个字节表示某个区间内所有的实数 . 而 2.13 你可以试着把它转换成 2进制。
所以在计算中如果有double的小数，会有误差。
但 decimal 本身应该没有， 所以需要看你是如何插入这个小数的，当然也要看你对这个字段的定义是什么？ 是 deciaml(, 还是double 这也是为会要检查你的表结构。
[/Quote]
计算机中所有数据的存储都是2进制的，但是大多数小数部分存储时只能用一个指定长度范围内的近似的2进制序列来存储。因此，数据库存储的大多数小数数据只是我们所期望的值的近似值然后通过某种规则（四舍五入到某一位）来显示出我们需要的值。
这两个数据中存在某种误差，而你UPDATE操作的对象是数据库物理存储的数据，这样，在经历100次UPDATE之后，这个误差就可能由量变引起质变。
引用而且见到过db2插值进去后，值会变成一个高精度近似数，比如，2.13,插进去有可能会变成2.1299999999
首先我们先达成共识, 计算机中无法用8或或N个字节表示某个区间内所有的实数 . 而 2.13 你可以试着把它转换成 2进制。
所以在计算中如果有double的小数，会有误差。
但 decimal 本身应该没有， 所以需要看你是如何插入这个小数的，当然也要看你对这个字段的定义是什么？ 是 deciaml(, 还是double 这也是为会要检查你的表结构。
[/Quote]
计算机中所有数据的存储都是2进制的，但是大多数小数部分存储时只能用一个指定长度范围内的近似的2进制序列来存储。因此，数据库存储的大多数小数数据只是我们所期望的值的近似值然后通过某种规则（四舍五入到某一位）来显示出我们需要的值。
这两个数据中存在某种误差，而你UPDATE操作的对象是数据库物理存储的数据，这样，在经历100次UPDATE之后，这个误差就可能由量变引起质变。
ACMAIN_CHM 2009-10-21
- 打赏
- 举报
应该不是BUG，
建议贴出来你的表结构，以及你的插入语句。你的db2版一，这样其它人也可以试一下。
建议贴出来你的表结构，以及你的插入语句。你的db2版一，这样其它人也可以试一下。
WWWWA 2009-10-21
- 打赏
- 举报
直接赋值没有经过计算，应该是BUG吧
liyan93834183 2009-10-21
- 打赏
- 举报
你应该先确定是不是proc的问题，如果真有这个问题，那你发现了一个DB2的bug啊，呵呵
Mr_Bean 2009-10-21
- 打赏
- 举报
数据库一直都有类似问题 但是我碰到的只是存储奇数尾数才会出 现在能缓解方法是decimal转为double
