SELECTクエリの算術オーバーフロー

単純なSELECTステートメントで算術オーバーフローが発生しました。クエリは以下のようになりました

SELECT [SaleValue] FROM Sales

[SaleValue]データ型decimal(9,0)であり、計算列ではありませんでした。

これが発生した理由は、このフィールドに指定されたデータ型よりも大きい値が格納されている行が列に含まれていたためdecimal(10,0)です。

列のサイズを大きくした場合にのみ、selectを機能させることができました。問題のテーブルには、他の2つの列と行に2つのインスタンスがあります。

この状況はどのようにして起こりましたか？そもそもどのように範囲外の値が列に保存されたのですか？

私はMicrosoft SQLサーバーを使用しています+これはベーステーブルであり、ビューではありません。

sql-server

私がこれを強制的に発生させる可能性があると考えられる唯一の方法は、DACを介してシステムテーブルを編集することです。これは、このDBに対して行われたかどうかを誰かが知らせてくれるかなり暴力的なプロセスです。それでも、うまくいくかどうかはわかりません。それ以外では、この状況を自分で確認するには再現スクリプトが本当に必要です。再現を作成するには、可能であれば、何年もの実験を簡単に行うことができると思います。

— Damien_The_Unbeliever

さらに悪いことに、9/10はストレージサイズのカットオーバーポイントであることを思い出してください-aは5バイト、9 を占有decimalするdecimal(9,0)必要がありますdecimal(10,0)。したがって、システムテーブルを編集することで、各行のデータの正しいストレージサイズ。

— Damien_The_Unbeliever

@Damien_The_Unbeliever再現方法がわからない。何が起こったのかを理解するのに1時間かかりました。乾いた水や冷たい熱を見るようなものでした。正直なところ、それは私を困らせました。

これは、たとえばSQL Server 2005以降のバージョンでのDBCCエラー2570のトラブルシューティングで説明されているように、いくつかの方法で発生する可能性があります。

次の理由により、無効なデータまたは範囲外のデータが以前のバージョンのSQL Serverデータベースに格納されていた可能性があります。

bcpユーティリティなどの一括挿入メソッドの使用中に、無効なデータがソースに存在しました。

SQL Serverに対して行われたRPCイベント呼び出しを通じて無効なデータが渡されました。

物理的なデータ破損のその他の潜在的な原因により、列の値が無効な状態のままになりました。

その記事には、このトピックに関する多くの役立つ情報が含まれています。基本については、特にのドキュメントDBCC CHECKDBおよびDATA_PURITYオプションを参照してください。

— ポールホワイト9
ソース