日時データ型には形式がありません。文字列型に変換すると、はい、ロケール対応の形式を適用できますが、内部的に日時はロケールに依存しません。
私の回答の前に、ADO.NET ソースは OLE のソースよりもはるかに苦痛です。
私の再現では、テーブルを作成し、そこにデータを貼り付ける Execute SQL タスクがあります。次に、データ フロー タスクにルーティングします。
データ フロー内で、 のクエリから始めますSELECT T.* FROM dbo.[Table] AS T
。現在、WHERE 句はありません。これは、データ フロー コンポーネントがソース クエリのメタ データを登録できるようにするためです。
パラメータ化するには、制御フロー レベルに戻る必要があります。データ フロー タスクを選択し、[プロパティ] で、ADO NET ソースの SqlCommand プロパティの式を追加する必要があります。
私の経験では、タスク自体で変数を作成するよりも、変数で式を作成し、変数をタスクのプロパティに割り当てる方が適切です。他の理由がなければ、このアプローチにより、ブレークポイントを設定してローカルを表示し、値を視覚的に調べることができます。これは、オブジェクトの式では実行できません。特に、式がパッケージの失敗の原因となっている場合はなおさらです。
このために、SSIS パッケージで 2 つの変数を定義したことがわかります。
- InputDateV - データ型は DateTime で、値は
10/24/2012 12:01 AM
単に表示するために時間コンポーネントを追加しましたが、必要に応じて削除できます。
- クエリ - データ型は文字列です。この変数のプロパティは EvaluateAsExpression = True で、式は
"SELECT T.* FROM dbo.[Table] T WHERE T.DateAdded > '" + (DT_WSTR, 24)@[User::InputDateV] + "'"
ここにあります ロケールに依存しない日時値を強制的にロケール対応型にしますが、これは .NET コードの魔法によるものであるため、機能します。
次に @[User::Query] を使用して [ADO NET Source].[SqlCommand] を構成すると、魔法のようにすべてが機能します。
偶然にも、変数名に関して上記の定義を誤解しました。@[User::InputDateV] が実際に String 型の場合、上記はうまくいきません。データ型文字列の変数 @[User::InputDateS] を作成し、値を割り当てました24/10/2012
。@[User::Query] 式を使用するように変更すると、SQL Server はその値を datetime データ型にできないため拒否します。そのため、SSIS 式に変換を実行させます。@[User::Query] の式を変更して
"SELECT T.* FROM dbo.[Table] T WHERE T.DateAdded > '" + (DT_WSTR, 24)((DT_DATE) @[User::InputDateS]) + "'"
、Bob's your uncle、パッケージ全体の緑色のボックスにします。
参照