1

次のクエリの違いを説明できますか

SELECT TO_CHAR(1980.55,'$9,999D999') FROM DUAL;

と

SELECT TO_CHAR(1980.55,'$9G999D999') FROM DUAL;

最初のクエリはエラーで失敗します。私が理解できないのは、グループ セパレータのデフォルトが「,」であるため、一方が失敗し、もう一方が正常に実行されるのはなぜですか。

4

1 に答える 1

2

興味深いことに、これまでに出会ったことはありませんが、なぜそれらを混ぜたいのか想像できません。ドキュメントやMSOにも何も見つからないので、推測します...

Gコンマ/ピリオドをグループ区切り文字/小数点文字（または）と混合すると発生するORA-01481エラーDは、「無効な数値形式モデル」です。これは、文字列を純粋に検証していることを示しています'$9,999D999'。この段階では、関数NLS_NUMERIC_CHARACTERに渡されたとしても、設定を認識していないようです。to_char()同じ検証が保存されたコード（プロシージャ、パッケージ、ビューなど）に適用され、キャッシュされたクエリがNLS設定（つまりハード解析）に基づいて再検証されることは期待できないため、これはそれほど不合理に思えません。

との意味を指定するcharの3番目の引数を使用すると、安全に実行できる可能性があると推測されますが、エッジケースでは多くの作業が必要になる可能性があり、それらをハードコーディングしている場合は、さらに少ないポイントがあります。とにかくモデルでそれらを混合します。GD

したがって、フォーマットモデル文字列が検証された時点で、実行時にどのように評価され、評価されるGかがわからない場合、ドキュメントに記載されている制限が問題になります。カンマはグループ区切り文字ですか、それとも10進文字ですか？実行時に10進文字がである場合、それらの1つしか持つことができないため、形式は無効になります。同様に、モデルがそうであった場合、グループ区切り文字がである場合は有効ですが、である場合は有効ではありません。実行時ではなく解析時に失敗する方が安全で信頼性が高いようです。D.'9.999G999'.,

言い換えると、「グループ区切り文字がデフォルトで」になるポイントは,、フォーマットモデルが検証された後なので、違いはありません。

しかし、私が言うように、内部について推測することは決して良い考えではありません。「カンマ[またはグループ区切り文字]は数値形式モデルの10進文字またはピリオドの右側に表示できない」と書かれている場合、ドキュメントは少し誤解を招くように思われます。これは、それらがまったく共存できないためです。ドキュメントのバグを提起する価値があるでしょうか？

同様の問題が8iに対するバグ1204892として発生し、「これは動作するように設計された方法です」というコメントでバグではないとしてクローズされました。

于 2013-02-01T16:58:53.677 に答える