@Edmundのアプローチに劣る代替手段は、別の変数で式を使用して文字列を構築することです。@[User::FirstName] が既に定義されていると仮定すると、別の変数 @[User::SourceQuery] を作成します。
この変数のプロパティで、EvaluateAsExpression を にTrue
設定し、次のような式を設定し"SELECT FirstName, LastName, FROM Person.Person WHERE FirstName = '" + @[User::FirstName] +"'"
ます。SSIS 文字列を構築しているため、二重引用符が必要です。
このアプローチを勧めるべきではない 2 つの大きな理由があります。
キャッシング
このアプローチは、本質的に同じクエリの N 個のコピーで SQL Server のプラン キャッシュを肥大化させます。初めて実行し、値が "Edmund" の場合、SQL Server は実行計画を作成して保存します (作成にはコストがかかるため)。次にパッケージを実行すると、値は「Bill」になります。SQL Server は、これに対する計画があるかどうかを確認します。そうではなく、Edmund 用に 1 つしかないため、計画の別のコピーを作成し、今度は Bill にハード コードします。泡だて洗いを繰り返し、いくつかの計画がアンロードされるまで、利用可能なメモリが減少するのを観察します。
パラメーター アプローチを使用すると、プランが SQL Server に送信されるときに、プランのパラメーター化されたバージョンが内部で作成され、提供されたすべてのパラメーターが等しいコストの実行になると想定されます。一般的に言えば、これは望ましい動作です。
データベースがアドホック ワークロード用に最適化されている場合 (既定ではオフになっている設定)、すべてのプランがパラメーター化されるため、これを軽減する必要があります。
SQL インジェクション
独自の文字列を作成する際に遭遇するもう 1 つの大きな問題は、SQL インジェクション攻撃にさらされるか、少なくとも実行時エラーが発生する可能性があることです。「d'Artagnan」の値を持つのと同じくらい簡単です。その一重引用符により、クエリが失敗し、パッケージが失敗します。値を "';DROP TABLE Person.Person;--" に変更すると、非常に苦痛になります。
すべてを安全に引用するのは些細なことだと思うかもしれませんが、クエリを実行するすべての場所で一貫してそれを実装する努力は、雇用主が支払っている金額を超えています。同じことを行うためにネイティブ機能が提供されているため、なおさらです。