4

これは、簡単な例の形で尋ねるのが一番だと思います。次の SQL チャンクは、「DB-Library Error:20049 Severity:4 Message:Data-conversion returned in overflow」メッセージを引き起こしますが、どうしてでしょうか? 

declare @a numeric(18,6), @b numeric(18,6), @c numeric(18,6)
select @a = 1.000000, @b = 1.000000, @c = 1.000000
select @a/(@b/@c)
go

これはどのように違うのですか:

select 1.000000/(1.000000/1.000000)
go

どちらがうまくいきますか？

4

4 に答える 4

4

最後に Sybase を使おうとしたとき (何年も前)、同じ問題に遭遇しました。SQL Server の考え方から来て、Sybase が小数を強制的に外そうとすることを認識していませんでした。:)

Sybaseマニュアルから：

新しい型の小数点以下の桁数が少なすぎて結果に対応できない場合、算術オーバーフロー エラーが発生します。

そしてさらに下：

数値型または小数型への暗黙的な変換中に、位取りが失われると位取りエラーが発生します。arithabort numeric_truncation オプションを使用して、このようなエラーがどの程度深刻であるかを判断してください。デフォルト設定の arithabort numeric_truncation on は、エラーの原因となったステートメントを中止しますが、トランザクションまたはバッチ内の他のステートメントの処理を続行します。arithabort numeric_truncation を off に設定すると、Adaptive Server はクエリ結果を切り捨てて処理を続行します。

したがって、精度の低下がシナリオで許容できると仮定すると、トランザクションの開始時に次のことが必要になる可能性があります。

SET ARITHABORT NUMERIC_TRUNCATION OFF

そして、トランザクションの最後に:

SET ARITHABORT NUMERIC_TRUNCATION ON

これが何年も前に私にとってそれを解決したものです...

于 2008-10-05T11:58:26.583 に答える
1

これは推測にすぎませんが、DBMS は変数の動的な値ではなく、潜在的な値だけを調べているのではないでしょうか? したがって、6 桁の数値を 6 桁の数値で割ると、12 桁の数値になる可能性があります。リテラル部では、DBMS はオーバーフローがないことを認識しています。ただし、なぜ DBMS が気にするのかはまだわかりません。2 つの 6 桁の除算の結果を最大 18 桁の数値として返す必要があるのではないでしょうか。

于 2008-10-03T19:29:17.047 に答える
1

最初の例で変数を宣言したため、結果は同じ宣言 (数値 (18,6)) であると予想されますが、そうではありません。

ただし、最初のものは SQL2005 で機能し (1.000000 [同じ宣言された型] を返しました)、2 番目のものは (1.0000000000000000000000 [まったく異なる宣言] を返しました) と言わざるを得ません。

于 2008-10-04T23:11:27.333 に答える