SSISにて変数を使用したSQL実行タスクの更新結果について

質問

はじめまして。
現在、SSISを使用して開発を行っています。
そこで、変数を使用したSQL実行タスクを構築したのですが、
ご存知の方はご回答願います。

処理内容としては、batプログラムにてdtexecでvalueというパラメータに0.7と渡します。
その後、SQL実行タスクのSQLstatementにて「UPDATE sample SET flag = '1' WHERE a <= ?」というように、
aの値がvalue以下だったら、フラグを更新するようなSQLをくみました。

実行し、確認をしたのですが、SSISを構築した端末で処理を行うと正しく更新されるのですが、
ビルドしたdtsxをサーバー上等、他の端末で実行すると、a=0.7のデータに対してフラグが更新されません。

ProtectionLevel値には、DontSaveSensitiveをセットしてあります。

何かご存知の方は、ご教示願います。

回答No.2

jamshid6 · ベストアンサー

端末依存というのは考えにくいですが、SQL実行タスクのパラメータのデータ型はDOUBLEなどを使っているのではないですか？
一番可能性が高いのは、「浮動小数点のデータ型を使っているから、SSISに正しく0.7と渡されていない」です。

ちなみに、変数のデータ型がSingleで、SQL実行タスクのパラメータのデータ型をDOUBLEにすると、0,7をセットしたとしても、こんなクエリがSQL Serverに投げられます。
exec sp_executesql N'UPDATE sample SET flag='1' WHERE a<=@P1',N'@P1 float',0.69999998807907104

SQL Serverのデータの優先順位はfloat,real>decimal,numericですから、実行されるクエリはdecimal(6,4)がfloatに変換されます。
しかし、SQL Serverではdecimal(6,4)をfloatに変換したときの丸め誤差はそれほど出ないようで、floatでも0.7です。
したがって、「aの値」>「パラメータの値」となる可能性があると思います。

こういう問題で悩みたくなければ、私ならばStringでパラメータを設定します。decimal>varcharですから、decimalで比較されます。

はたして質問者さんのケースが、上記に該当するかどうかは、以下の２つの方法で確認することをお勧めします。
・SQL Server プロファイラでSSISのSQL実行タスクが投げるSQL文をトラップする
・変数をString、パラメータをVARCHARで設定しても、同じ事象が発生するか確認する

参考になれば。。

お礼

ご指摘いただいた通り、SQL実行タスクのパラメータのデータ型にはDOUBLEを使っていました。

>・変数をString、パラメータをVARCHARで設定しても、同じ事象が発生するか確認する
を行い確認してみた所、他端末でも正しく0.7以下のデータに対してフラグ更新されている事が確認できました。
詳しく説明いただき誠にありがとうございました。
大変参考になりました。

ただ、なぜ開発端末では再現しないのかが未だ不明点です。。

補足

変数/パラメータの型を変更し正常起動を確認したので、開発には問題ないのですが、
プロファイルでSQLをトラップした所、開発端末、他端末ともに下記の同様のSQLが実行されていました。

exec sp_executesql N'UPDATE sample SET flag = ''1'' WHERE a <= @P1,N'@P1 float',0.7

結果は、やはり開発端末では、0.7以下のデータのフラグが更新され、他端末では、0.7未満のデータのフラグが更新されていました。。。

>しかし、SQL Serverではdecimal(6,4)をfloatに変換したときの丸め誤差はそれほど出ないようで、floatでも0.7です。
>したがって、「aの値」>「パラメータの値」となる可能性があると思います。
jamshid6様のご意見の中で、floatでも0.7なのに「aの値」>「パラメータの値」となる可能性があるとおっしゃっているのは、どのような見解なのでしょうか？
floatでも0.7であれば、「aの値」<=「パラメータの値」と判断され、0.7のデータは更新されると思ってしまうのですが・・・。

大変申し訳ございませんが、もう少々お付き合い願います。

回答No.3

jamshid6

#1,#2です。
私の書いた趣旨は、「SSISが0.7ではなく丸め誤差の生じた値をSQL Serverに渡しているのであれば」ということが前提となっているので、
もし本当に0.7で渡されているのであれば、私の推論は成り立たないです。
（こちらで変数Single、パラメータDOUBLEで設定すると0.69999998807907104が渡されていましたけどね）

そうすると理由は別のところにあるのでしょうが、残念ながら思い当たりません。

お礼

>私の書いた趣旨は、「SSISが0.7ではなく丸め誤差の生じた値をSQL Serverに渡しているのであれば」ということが前提となっているので、
>もし本当に0.7で渡されているのであれば、私の推論は成り立たないです。
>（こちらで変数Single、パラメータDOUBLEで設定すると0.69999998807907104が渡されていましたけどね）

検証までして頂き誠にありがとうございました。
上記の件、了解いたしました。
大変助かりました。

回答No.1

jamshid6

情報を見る限り、正常終了しているとは考えにくいのですが
・バッチファイルを叩いているということですが、実行ログにはどう書かれていますか？
・パッケージ内のSQL Serverへの接続はWindows認証ですか？
・コマンドラインからパラメータはどのように指定していますか？
・念のため、「0.7は更新されないけど、0.6は更新されている。フィールドはFloat」とかそういう話ではないですよね？

補足

jamshid6様

ご連絡ありがとうございます。
・バッチファイルを叩いているということですが、実行ログにはどう書かれていますか？
→実行ログは正常終了で完了しています。
・パッケージ内のSQL Serverへの接続はWindows認証ですか？
→SQL Server認証で接続しています。接続情報は変数でバッチから渡し、
Expessionsにて、ConnectionStringを成型しています。
・コマンドラインからパラメータはどのように指定していますか？
→/SET \package.variables[User::value].Value;0.7
・念のため、「0.7は更新されないけど、0.6は更新されている。フィールドはFloat」とかそういう話ではないですよね？
→0.7未満のデータについては、フラグはしっかり更新されています。
フラグのデータ型はcharで、aのデータ型はdecimal(6,4)。
ちなみに、SSISの変数の型はsingleとしています。

異常終了となっていたら、まだわかりやすかったのですが、
正常終了していて、端末によって結果が異なってしまう為、頭を悩ましています。

よろしくお願いいたします。