Requête source OLEDB paramétrée

Je suis entrain de créer un ETL SSIS dans lequel je qui je tiens ma source de données soit restreint de requête, comme select * from table_name where id='Variable'. Cette variable est ce que j'ai défini comme Utilisateur créé variable.

Je ne comprends pas comment je peux avoir ma requête source d'interagir avec SSIS d'étendue Variable.

Le seul présenter des options sont

  • Table
  • Table à partir d'une variable
  • Commande SQL
  • Commande SQL à partir d'une variable

Ce que je veux, c'est avoir une instruction SQL d'avoir une variable comme paramètre

source d'informationauteur

  1. 16

    Simple. Choisissez SQL command que le Mode d'Accès aux Données. Entrez votre requête avec un point d'interrogation comme un paramètre de l'espace réservé. Puis cliquez sur le Parameters bouton et carte votre variable Parameter0 dans le Set Query Parameters dialogue:

    Requête source OLEDB paramétrée

    Plus d'informations sont disponibles sur MSDN.

  2. 7

    Inférieure alternative à @Edmund et de son approche est d'utiliser une Expression à une autre Variable pour construire votre chaîne. En supposant que vous avez @[Utilisateur::FirstName] déjà défini, vous pouvez alors créer une autre variable, @[Utilisateur::SourceQuery].

    Dans les propriétés de cette variable, ensemble EvaluateAsExpression à True et ensuite définir une Expression comme "SELECT FirstName, LastName, FROM Person.Person WHERE FirstName = '" + @[User::FirstName] +"'" Les guillemets sont nécessaires parce que nous sommes la construction d'une SSIS Chaîne.

    Il y a deux grandes raisons, cette approche ne devrait pas être imploré.

    La mise en cache

    Cette approche va gonfler votre plan de cache SQL Server avec N copies de essentiellement la même requête. La première fois, il s'exécute et la valeur est "Edmund" SQL Server va créer un plan d'exécution et de l'enregistrer (car il peut être coûteux à construire). Ensuite, vous exécutez le package et la valeur est le "projet de Loi". SQL Server vérifie pour voir si il a un plan pour cela. Il ne l'a pas, il n'a qu'un pour l'Edmund, et donc, il en crée une autre copie du plan, cette fois codé en dur sur le projet de Loi. Faire mousser rincer-répéter et regarder votre mémoire disponible diminuer jusqu'à ce qu'il se décharge de certains régimes.

    En utilisant le paramètre approche, lorsque le plan est soumis à SQL Server, il convient de créer une version paramétrée du plan interne et suppose que tous les paramètres fournis à assurer l'égalité des coûts d'exécutions. En général, c'est le comportement souhaité.

    Si votre base de données est optimisé pour les réseaux ad-hoc de la charge de travail (c'est un paramètre désactivée par défaut), qui doivent être atténués dans chaque plan est d'aller pour obtenir paramétrée.

    Injection SQL

    L'autre grand méchant vous dans la construction de votre propre chaîne, c'est que vous vous ouvrez à des attaques par Injection SQL ou à tout le moins, vous pouvez obtenir des erreurs d'exécution. C'est aussi simple que d'avoir une valeur de "d'Artagnan." Cette seule citation sera la cause de votre échec de la requête résultant en échec de package. La modification de la valeur "';DROP TABLE Personne.Personne;--" sera dans une grande douleur.

    Vous pourriez penser que c'est trivial pour la sécurité de citer tout mais l'effort de la mise en œuvre de façon uniforme partout vous interrogez-delà de ce que votre employeur de vous payer. D'autant plus qu'il y a une fonctionnalité native à condition de faire la même chose.