數量在格式化爲TO_CHAR面膜（）

Question

你能解釋一下下面的查詢

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

和

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

第一個查詢失敗，錯誤的區別，我不明白的是，組分隔符默認爲'，'爲什麼一個失敗，另一個成功執行。

Answer 1

有趣的是，之前沒有遇到過，但後來無法想象你爲什麼要混合它們。我找不到任何文檔或甚至MSO，所以我會推測...

從混合逗號/句點與組分隔符/十進制字符（G或D）得到的ORA-01481錯誤，是'無效數字格式模型'，這表明它純粹驗證字符串'$9,999D999'。看起來在這個階段它不知道你的NLS_NUMERIC_CHARACTER設置，即使它被傳遞到to_char()函數。這看起來似乎不太合理，因爲相同的驗證將應用於存儲的代碼（過程，包，視圖或其他），並且您不希望基於NLS設置（即，硬解析）重新驗證緩存的查詢。

據猜測它可能潛在與第三個參數爲char指定的G和D含義安全進行，但是，似乎是它可能是一個大量的工作，爲邊緣的情況下，如果你是硬對它們進行編碼，無論如何在模型中混合它們甚至更少。

因此，如果在該格式字符串模型驗證它不知道如何G和D將在運行時進行評估來看，restrictions listed in the documentation成爲一個問題。你的逗號應該是一個組分隔符還是小數字符？如果在運行時你的十進制字符是.，那麼格式將是無效的，因爲你只能有其中一個。同樣，如果模型爲'9.999G999'，那麼如果您的組分隔符是.，那麼它將是有效的，但如果它是,則不適用。解析時間而不是運行時間似乎更安全，更可靠。

，或者換一種說法，其中「組分隔符默認爲,」是後的格式模型已經被驗證，所以也沒有任何區別點。

但是，正如我所說，揣測內部，這從來不是一個好主意。當它說'逗號[或組分隔符]不能出現在數字格式模型的小數字符或句點的右側「時，文檔似乎有點誤導，因爲它們根本不能共存。值得提出一個文檔錯誤？

---

類似的問題有人提出了錯誤1204892針對8I，並與評論「這是它的設計工作方式」關閉不-A-錯誤。