0

我遇到了他更新查询的问题。我将 balance1 字段更新为 6442450941.026600。

update account_subscriber set total_balance1=6442450941.026600
 where SUB_ID='xyz'

但结果如下（在触发 select stmt 后我们得到）

TOTAL_BALANCE1 6442450941.02659988

第二种情况：让我们使用以下值进行更新

update account_subscriber set total_balance1=6442450941.4567
 where SUB_ID='xyz'

结果为 6442450941.45670032。

您能否帮助我理解为什么精度会发生变化。

sql*plus version is version is 10.2.0.3.0

谢谢和问候， Chandra Bhushan Bakshi

4

4 回答 4

3

我能想出的唯一解释是，在您的数据库和显示它的路径之间的某个位置，它被转换为浮点值。我使用 PL/SQL Developer 作为我的 Oracle 开发工具，并认为它非常可靠。因此，当我运行以下命令时，想象一下我的惊讶：

create TABLE rpj_test (val number(22, 8));

INSERT INTO rpj_test(val) VALUES (6442450941.026600);

SELECT * FROM rpj_test;

我得到了你报告的确切结果（6442450941.02659968）。WTF?!?!?

但后来我问自己一个重要的问题——我如何测试这个以确保正确的数据实际上在数据库中？所以我运行了以下查询：

SELECT val * 10000 FROM rpj_test;

并得到了我预期的答案（64424509410266）。

所以看起来数据库中的数据是正确的。这并不奇怪——我认为 Oracle 的 NUMBER 类型是该产品中最不受重视的特性之一，它一直存在，而且它坚如磐石（如果我们希望我们的系统有任何正常工作的机会，最好是这样：- ）。好的，所以在我看来，这看起来像是一个浮点转换错误——我能做些什么呢？因此，我在 PL/SQL Developer 的 Preferences 配置对话框中四处寻找，在那里我在 SQL Window 选项卡上找到了一个名为“Number fields to_char”的简洁小设置，该设置没有被选中。我检查了这个，重新运行了第一个 SELECT 查询，你瞧，数据按预期呈现。

故事寓意：

  1. NUMBER 正确计算和存储。如果您认为自己发现了一个错误，请认真思考一遍又 一遍。以十六种不同的方式对其进行测试。弄清楚如何证明这实际上不是一个错误。
  2. 您使用的工具会影响您获得的结果。

分享和享受。

于 2012-08-23T17:22:07.003 回答
0

这只是一个 pl/sql 开发人员显示问题。在 PL/SQL 开发人员中，选择工具菜单和首选项选项，在 SQL 窗口类型和数字布局中取消选中格式化选项并选择任何其他选项并查看正确的结果。:)

于 2012-08-23T15:40:18.830 回答
0

您提供的值无法通过接收列的数据类型解析为所需的精度。如果您需要精确到百万分之一，正如问题所暗示的那样，您应该检查表字段数据类型的精度并进行相应调整。

于 2012-08-23T13:22:03.183 回答
0

这是因为您使用的数据类型不精确。

于 2012-08-23T13:22:16.017 回答