無論你做了多少測試（嗯，它實際上是這樣，但這是一個完全不同的問題），你幾乎可以保證，在某些時刻，你那些漂亮的資料驗證代碼，在解析從web表單輸入的資料或從外部加載資料檔案時，會彈出錯誤：
當然，這裡真正令人讨厭的是，你不知道哪個列的值（假設你有多個數字列）。
在資料加載期間管理轉換錯誤
怎麼辦？ 當然，明智的是，在你的代碼中添加大量的資料驗證檢查，以嘗試捕獲來自資料源的錯誤類型資料所到達的情況。很可能所有的附加驗證檢查将減慢插入資料的過程，但這不是一個很好的結果。
如果您的資料通過外部檔案到達，那麼您可以使用badfile子句捕獲那些由于資料類型錯誤而無法加載的記錄。 但是，如果插入語句的資料源是由etl作業填充的中間表或來自網頁表單的一系列值，又該怎麼辦？
如何在insert期間管理轉換錯誤
panic over - database 12c版本2包含了對cast和to_xxx函數的重要更改，以管理最常見的資料轉換錯誤。 如果存在轉換錯誤，cast函數現在可以傳回使用者指定的值。
例如，讓我們在模式中建構一個簡單的計劃表：
并讓我們插入一些資料，其中包括在我們嘗試将值添加到目标表中時可能導緻資料轉換錯誤的值：
現在讓我們試着将資料從我們的分期表插入到emp表，看看會發生什麼：
……毫不意外的，我得到了以下錯誤：
我可以用幾種不同的方式來處理這種情況。首先，嘗試并發現臨時表中的哪些行和列會包含導緻資料轉換錯誤的值。為此，我将使用新的validate_conversion（）函數，該函數辨別無法轉換為所需資料類型的問題資料。如果給定的表達式可以轉換為指定的資料類型，則傳回1，否則傳回0。
這将産生一個表，其中我可以輕松地選擇資料轉換将要成功（列值為1）和失敗（列值為0）的行：
我可以使用此資訊過濾臨時表中的資料，因為我将其插入到我的emp表或我可以使用insert into ... .. select語句中增強的cast和to_xxx函數。
當發生資料類型轉換錯誤時，cast函數（以及to_number，to_binary_float，to_binary_double，to_date，to_timestamp，to_timestamp_tz，to_dsinterval和to_yminterval函數）現在可以傳回使用者指定的值，而不是錯誤。這減少了資料轉換和資料加載過程中的故障。
是以，我新的12.2版本驗證select語句如下所示：
這五行結果插入到我的emp表中 - 顯然這意味着在插入過程（行1,4,6和8）期間拒絕了第4行，因為它們包含将内容轉換為empno鍵的一個數字錯誤。 這裡是加載的資料：
我們可以看到在第1行，hierdate無效，是以它被替換為sys日期（07-jul-16）的值。 第2行，deptno的值是轉換預設值99，而在第4行，mgr的值是轉換預設值9999。
總結
增強的cast函數（以及to_number，to_binary_float，to_binary_double，to_date，to_timestamp，to_timestamp_tz，to_dsinterval和to_yminterval函數）可幫助您處理資料轉換錯誤，而無需使用複雜的pl / sql代碼或在應用程式代碼中寫入資料驗證例程。
新的validate_conversion（）函數可用于幫助您辨別無法轉換為所需資料類型的列值。
這兩個功能都很有用。希望你會喜歡！
原文釋出時間為：2017-03-24
本文來自雲栖社群合作夥伴dbaplus