qty
実際にフィールドであることを考えると、あなたが示した結果を得ることができる唯一の方法number
は、それが破損したデータを保持している場合です (そのため、その仮定について懐疑的です)。また、クライアントが先頭のゼロで値をフォーマットしていると仮定していますが、通常は表示されない末尾のゼロを強制していません。もちろん、 で強制することもできますが、to_char(.0008, '0.00000')
そうしているようには見えません。それでも、先頭のゼロは私を驚かせます。
とにかく、破損を実証するために、PL/SQL を介してフィールドに無効な値を強制することができます。実際のデータや関心のあるテーブルでこれを試さないでください。
create table t42(qty number);
table T42 created.
declare
n number;
begin
dbms_stats.convert_raw_value('bf0901', n);
insert into t42 (qty) values (n);
end;
/
anonymous block completed
select qty from t42;
QTY
----------
.00080
select to_number(qty) from t42;
Error starting at line : 12 in command -
select to_number(qty) from t42
Error report -
SQL Error: ORA-01722: invalid number
01722. 00000 - "invalid number"
単純なクエリでは、数値が期待どおりに表示されることに注意してください。ただし、末尾にゼロがあり、先頭にゼロはありません。実行すると、to_number()
ORA-01722 がスローされます。先頭のゼロは別として、それがあなたが示したものです。
to_char()
質問のタイトルのように、それも失敗します:
select to_char(qty) from t42;
Error starting at line : 13 in command -
select to_char(qty) from t42
Error report -
SQL Error: ORA-01722: invalid number
...これは理にかなっています。あなたto_number()
は暗黙的な変換を行っているので、それは本当にto_number(to_char(qty))
であり、実際にエラーを生成するのは暗黙的to_char()
だと思います。
あなたのコメントは、データをロードおよび削除するプロセスがあることを示唆しています。それが何をしているのか、そしてそれが腐敗を引き起こしている可能性があるかどうかを正確に見ることは興味深いでしょう. 上記の PL/SQL の例のように、データベースは渡されたデータが有効であると信頼するため、この種の効果は OCI を介して実現できます。imp
破損を引き起こす可能性があることを示唆するバグ レポートもあります。そのため、正確なデータベースのバージョンとプラットフォームと同様に、ロード プロセスの詳細が重要になる場合があります。