Tache d'exécution de requêtes SQL

Article
12/15/2008

Mis à jour : 15 septembre 2007

La tâche d'exécution de SQL exécute des instructions ou des procédures stockées SQL à partir d'un package. La tâche peut contenir une seule ou plusieurs instructions SQL s'exécutant de façon séquentielle. Vous pouvez utiliser la tâche d'exécution SQL aux fins suivantes :

Tronquer une table ou une vue pour la préparer à l'insertion de données.
Créer, modifier et supprimer des objets de base de données tels que des tables et des vues.
Recréer des tables de faits et de dimensions avant d'y charger des données.
Exécuter des procédures stockées.
Enregistrer dans une variable l'ensemble de lignes retourné par une requête.

Vous pouvez configurer la tâche d'exécution SQL comme suit :

Spécifiez le type de gestionnaire de connexions à utiliser pour établir la connexion à une base de données.
Spécifiez le type d'ensemble de résultats retourné par l'instruction SQL.
Spécifiez un délai d'expiration pour les instructions SQL.
Spécifiez la source de l'instruction SQL.
Indiquez si la tâche passe la phase de préparation de l'instruction SQL.
Si vous utilisez le type de connexion ADO, indiquez si l'instruction SQL est une procédure stockée. Pour d'autres types de connexion, cette propriété est définie en lecture seule et sa valeur est toujours false.

Vous pouvez combiner la tâche d'exécution SQL et les conteneurs de boucles Foreach et For pour exécuter plusieurs instructions SQL. Ces conteneurs mettent en œuvre des flux de contrôle répétitifs dans un package et peuvent exécuter la tâche d'exécution SQL de façon répétée. Par exemple, à l'aide du conteneur de boucles Foreach, un package peut passer en revue les fichiers d'un dossier et exécuter une tâche d'exécution SQL de façon répétée afin d'exécuter l'instruction SQL stockée dans chaque fichier.

Connexion à une source de données

La tâche d'exécution SQL peut utiliser différents types de gestionnaires de connexions pour se connecter à la source de données dans laquelle elle exécute l'instruction ou la procédure stockée SQL. La tâche peut utiliser les types de connexions décrits dans le tableau suivant.

Type de connexion	Gestionnaire de connexions
EXCEL	Gestionnaire de connexions Excel
OLE DB	Gestionnaire de connexions OLE DB
ODBC	Gestionnaire de connexions ODBC
ADO	Gestionnaire de connexions ADO
ADO.NET	Gestionnaire de connexions ADO.NET
SQLMOBILE	Gestionnaire de connexions de SQL Server Compact Edition

Création d'instructions SQL

La source des instructions SQL utilisée par cette tâche peut être une propriété de tâche contenant une instruction, une connexion à un fichier contenant une ou plusieurs instructions ou le nom d'une variable contenant une instruction. Les instructions SQL doivent être écrites dans le langage du système de gestion de bases de données (SGBD) source.

Si les instructions SQL sont stockées dans un fichier, la tâche utilise un gestionnaire de connexions de fichiers pour se connecter au fichier. Pour plus d'informations, consultez Gestionnaire de connexions de fichiers.

Dans le concepteur SSIS, vous pouvez utiliser la boîte de dialogue Éditeur de tâche d'exécution SQL pour taper des instructions SQL ou utiliser le générateur de requêtes, une interface graphique utilisateur permettant de créer des requêtes SQL.

Remarque :
Les instructions SQL valides écrites en dehors de la tâche d'exécution SQL peuvent ne pas être analysées correctement par celle-ci.

Envoi de plusieurs instructions dans un lot d'instructions

Si vous incluez plusieurs instructions dans une tâche d'exécution SQL, vous pouvez les regrouper et les exécuter sous forme de lot. Pour indiquer la fin d'un lot d'instructions, utilisez la commande GO. Toutes les instructions SQL comprises entre deux commandes GO sont envoyées dans un lot d'instructions au fournisseur OLE DB afin d'être exécutées. La commande SQL peut comprendre plusieurs lots d'instructions séparés par des commandes GO.

Il existe des restrictions sur les types d'instructions SQL pouvant être regroupées dans un lot d'instructions. Pour plus d'informations, consultez Batches of Statements.

Si la tâche d'exécution SQL exécute un lot d'instructions SQL, les règles suivantes s'appliquent à celui-ci :

Une seule instruction peut retourner un ensemble de résultats et il doit s'agir de la première instruction du lot d'instructions.
Si l'ensemble de résultats utilise des liaisons de résultats, les requêtes doivent retourner le même nombre de colonnes. Si les requêtes retournent un nombre différent de colonnes, la tâche échoue. Toutefois, même si la tâche échoue, les requêtes qu'elle exécute, telles que les requêtes DELETE ou INSERT, peuvent réussir.
Si les liaisons de résultats utilisent des noms de colonne, la requête doit retourner des colonnes portant les mêmes noms que l'ensemble de résultats utilisé par la tâche. Si les colonnes sont manquantes, la tâche échoue.
Si la tâche utilise la liaison de paramètre, toutes les requêtes du lot d'instructions doivent avoir le même nombre et les mêmes types de paramètres.

Exécution de commandes SQL paramétrées

Les instructions et les procédures stockées SQL utilisent fréquemment des paramètres d'entrée, des paramètres de sortie et des codes de retour. La tâche d'exécution SQL prend en charge les types de paramètres Input, Output et ReturnValue. Vous utilisez le type Input pour les paramètres d'entrée, Output pour les paramètres de sortie et ReturnValue pour les codes de retour.

Remarque :
Vous ne pouvez utiliser des paramètres dans une tâche d'exécution SQL que si le fournisseur de données les prend en charge.

Les paramètres des commandes SQL, notamment les requêtes et les procédures stockées, sont mappés à des variables définies par l'utilisateur créées dans l'étendue de la tâche d'exécution SQL, un conteneur parent ou dans l'étendue du package. Les variables peuvent être définies au moment de la conception ou remplies dynamiquement lors de l'exécution. Vous pouvez également mapper des paramètres à des variables système. Pour plus d'informations, consultez Variables Integration Services et Variables système.

Selon le type de connexion que la tâche d'exécution SQL utilise, la syntaxe de la commande SQL utilise différents marqueurs de paramètres. Par exemple, le type de gestionnaire de connexions ADO.NET impose que la commande SQL utilise un marqueur de paramètre de format @varParameter, tandis que le type de connexion OLE DB nécessite le marqueur de paramètre point d'interrogation (?).

Les noms que vous pouvez utiliser comme noms de paramètres dans les mappages entre variables et paramètres varient également selon le type de gestionnaire de connexions. Par exemple, le type de gestionnaire de connexions ADO. NET utilise un nom défini par l'utilisateur à préfixe @, tandis que le type de gestionnaire de connexions OLE DB impose l'utilisation de la valeur numérique d'un ordinal de base 0 comme nom de paramètre.

Le tableau suivant indique les conditions requises des commandes SQL pour les types de gestionnaires de connexions que la tâche d'exécution SQL peut utiliser.

Type de connexion	Marqueur de paramètre	Nom du paramètre	Exemple de commande SQL
ADO	?	Param1, Param2, …	SELECT FirstName, LastName, Title FROM Person.Contact WHERE ContactID = ?
ADO.NET	@<nom du paramètre>	@<nom du paramètre>	SELECT FirstName, LastName, Title FROM Person.Contact WHERE ContactID = @parmContactID
ODBC	?	1, 2, 3, …	SELECT FirstName, LastName, Title FROM Person.Contact WHERE ContactID = ?
EXCEL et OLE DB	?	0, 1, 2, 3, …	SELECT FirstName, LastName, Title FROM Person.Contact WHERE ContactID = ?

Paramètres avec les gestionnaires de connexions ADO.NET

Les gestionnaires de connexions ADO.NET imposent que la commande SQL utilise des noms de paramètres comme marqueurs de paramètres. Cela signifie que des variables peuvent être mappées directement à des paramètres. Par exemple, la variable @varName est mappée au paramètre nommé @parName et fournit une valeur au paramètre @parName.

Paramètres avec les gestionnaires de connexions EXCEL, ODBC et OLE DB

Les gestionnaires de connexions EXCEL, ODBC et OLE DB imposent que la commande SQL utilise des points d'interrogation (?) comme marqueurs de paramètres et des valeurs numériques de base 0 et de base 1 comme noms de paramètres. Si la tâche d'exécution SQL utilise le gestionnaire de connexions ODBC, le nom de paramètre mappé au premier paramètre dans la requête se nomme 1 ; sinon, le paramètre se nomme 0. Pour les paramètres suivants, la valeur numérique du nom du paramètre indique le paramètre dans la commande SQL auquel est mappé le nom du paramètre. Par exemple, le paramètre nommé 3 est mappé au troisième paramètre, qui est représenté par le troisième point d'interrogation (?) dans la commande SQL.

Pour fournir des valeurs aux paramètres, les variables sont mappées à des noms de paramètres et la tâche d'exécution SQL utilise la valeur ordinale du nom du paramètre pour charger des valeurs de variables dans des paramètres.

Si la tâche d'exécution utilise le type de connexion OLE DB, la propriété BypassPrepare de la tâche est disponible. Vous devez attribuer à cette propriété la valeur true si la tâche d'exécution de requêtes SQL utilise des instructions SQL avec des paramètres.

Lorsque vous utilisez un gestionnaire de connexions OLE DB, vous ne pouvez pas utiliser de sous-requêtes paramétrées car la tâche d'exécution de requêtes SQL ne peut pas dériver d'informations sur les paramètres par le biais du fournisseur OLE DB. Toutefois, vous pouvez utiliser une expression pour concaténer les valeurs de paramètres dans la chaîne de requête et définir la propriété SqlStatementSource de la tâche.

Selon le fournisseur que le gestionnaire de connexions utilise, certains types de données OLE DB risquent de ne pas être pris en charge. Par exemple, le pilote Excel ne reconnaît qu'un ensemble limité de types de données. Pour plus d'informations sur le comportement du fournisseur Jet avec le pilote Excel, consultez Source Excel.

Paramètres avec les gestionnaires de connexions ADO

Les gestionnaires de connexions ADO imposent que la commande SQL utilise des points d'interrogation (?) comme marqueurs de paramètres, mais vous pouvez utiliser un nom défini par l'utilisateur, à l'exception des valeurs entières, comme noms de paramètres.

Pour fournir des valeurs aux paramètres, les variables sont mappées à des noms de paramètres et la tâche d'exécution SQL utilise la valeur ordinale du nom du paramètre dans la liste de paramètres pour charger des valeurs de variables dans des paramètres.

Utilisation de paramètres avec des clauses WHERE

Les commandes SELECT, INSERT, UPDATE et DELETE incluent fréquemment des clauses WHERE pour spécifier des filtres qui définissent les conditions que chaque ligne des tables sources doit satisfaire pour se qualifier pour une commande SQL. Les paramètres fournissent les valeurs de filtre dans les clauses WHERE.

Vous pouvez utiliser des marqueurs de paramètres pour fournir dynamiquement des valeurs de paramètres. Les règles pour lesquelles des marqueurs de paramètres et des noms de paramètres peuvent être utilisés dans l'instruction SQL varient selon le type de gestionnaire de connexions que la tâche d'exécution SQL utilise.

Le tableau suivant présente des exemples de la commande SELECT par type de gestionnaire de connexions. Les instructions INSERT, UPDATE et DELETE sont similaires. Les exemples utilisent SELECT pour retourner des produits de la table Product dans AdventureWorks qui ont un ProductID supérieur et inférieur aux valeurs spécifiées par les deux paramètres.

Type de connexion	Syntaxe SELECT
EXCEL, ODBC et OLEDB	`SELECT* FROM Production.Product WHERE ProductId > ? AND ProductID < ?`
ADO	`SELECT* FROM Production.Product WHERE ProductId > ? AND ProductID < ?`
ADO.NET	`SELECT* FROM Production.Product WHERE ProductId > @parmMinProductID AND ProductID < @parmMaxProductID`

Les exemples exigeraient alors des paramètres avec les noms suivants :

Les gestionnaires de connexions EXCEL et OLE DB utilisent les noms de paramètres 0 et 1. Le type de connexion ODBC utilise 1 et 2.
Le type de connexion ADO peut utiliser deux noms de paramètres (par exemple, Param1 et Param2) mais les paramètres doivent être mappés selon leur position ordinale dans la liste des paramètres.
Le type de connexion ADO.NET utilise les noms de paramètres @parmMinProductID et @parmMaxProductID.

Utilisation de paramètres avec des procédures stockées

Les commandes SQL qui exécutent des procédures stockées peuvent également utiliser le mappage de paramètres. Les règles d'utilisation des marqueurs de paramètres et des noms de paramètres varient selon le type de gestionnaire de connexions que la tâche d'exécution SQL utilise, tout comme les règles des requêtes paramétrées.

Le tableau suivant présente des exemples de la commande EXEC par type de gestionnaire de connexions. Les exemples exécutent la procédure stockée uspGetBillOfMaterials dans AdventureWorks. La procédure stockée utilise les paramètres d'entrée @StartProductID et @CheckDate.

Type de connexion	Syntaxe EXEC
EXCEL et OLEDB	`EXEC uspGetBillOfMaterials ?, ?`
ODBC	`{call uspGetBillOfMaterials(?, ?)}` Pour plus d'informations sur la syntaxe d'appel d'ODBC, consultez la rubrique Paramètres de procédures dans le Guide de référence du programmeur ODBC dans MSDN Library.
ADO	Si IsQueryStoredProcedure prend la valeur False, `EXEC uspGetBillOfMaterials ?, ?` Si IsQueryStoredProcedure prend la valeur True, `uspGetBillOfMaterials`
ADO.NET	Si IsQueryStoredProcedure prend la valeur False, `EXEC uspGetBillOfMaterials @StartProductID, @CheckDate` Si IsQueryStoredProcedure prend la valeur True, `uspGetBillOfMaterials`

Pour utiliser des paramètres de sortie, la syntaxe impose que le mot clé OUTPUT suive chaque marqueur de paramètre. Par exemple, EXEC myStoredProcedure ? OUTPUT.

Pour plus d'informations sur l'utilisation de paramètres d'entrée et de sortie avec des procédures stockées Transact-SQL, consultez Paramètres (Moteur de base de données), Retour de données à l'aide de paramètres OUTPUT et EXECUTE (Transact-SQL).

Obtention de valeurs de codes de retour

Une procédure stockée peut retourner une valeur entière appelée « code de retour » pour indiquer l'état d'exécution d'une procédure. Pour implémenter des codes de retour dans la tâche d'exécution SQL, vous utilisez des paramètres du type ReturnValue.

Le tableau suivant présente par type de connexion des exemples de commandes EXEC qui implémentent des codes de retour. Tous les exemples utilisent un paramètre d'entrée. Les règles d'utilisation des marqueurs de paramètres et des noms de paramètres avec des paramètres ReturnValue sont identiques à celles qui s'appliquent aux types de paramètres Input et Output.

Certaine syntaxes ne prennent pas en charge les littéraux de paramètres. Dans ce cas, vous devez fournir la valeur du paramètre en utilisant une variable.

Type de connexion	Syntaxe EXEC
EXCEL et OLEDB	`EXEC ? = myStoredProcedure 1`
ODBC	`{? = call myStoredProcedure(1)}` Pour plus d'informations sur la syntaxe d'appel d'ODBC, consultez la rubrique Paramètres de procédures dans le Guide de référence du programmeur ODBC dans MSDN Library.
ADO	Si IsQueryStoreProcedure prend la valeur False, `EXEC ? = myStoredProcedure 1` Si IsQueryStoreProcedure prend la valeur True, `myStoredProcedure`
ADO.NET	Si IsQueryStoreProcedure prend la valeur True. `myStoredProcedure`

Pour plus d'informations sur l'utilisation de codes de retour avec des procédures stockées Transact-SQL, consultez Renvoi de données au moyen d'un code de retour et RETURN (Transact-SQL).

Spécification d'un type d'ensemble de résultats

Selon le type de commande SQL, un ensemble de résultats peut ou non être retourné à la tâche d'exécution SQL. Par exemple, une instruction SELECT retourne généralement un ensemble de résultats, contrairement à une instruction INSERT. L'ensemble de résultats issu d'une instruction SELECT peut contenir un nombre de lignes quelconque (aucune ligne, une ligne ou de nombreuses lignes). Les procédures stockées peuvent également retourner une valeur entière, appelée « code de retour », qui indique l'état de leur exécution. Dans ce cas, l'ensemble de résultats comprend une seule ligne.

La tâche d'exécution SQL prend en charge les types suivants de jeux de résultats :

L'ensemble de résultats Aucun est utilisé lorsque la requête ne retourne aucun résultat. Par exemple, cet ensemble de résultats est utilisé pour les requêtes qui ajoutent, modifient et suppriment des enregistrements dans une table.
L'ensemble de résultats Ligne unique est utilisé lorsque la requête ne retourne qu'une seule ligne. Par exemple, cet ensemble de résultats est utilisé pour une procédure stockée qui retourne un code de retour ou pour une instruction SELECT qui retourne un décompte ou une somme.
L'ensemble de résultats Ensemble de résultats complet est utilisé lorsque la requête retourne plusieurs lignes. Par exemple, cet ensemble de résultats est utilisé pour une instruction SELECT qui extrait toutes les lignes d'une table.
L'ensemble de résultats XML est utilisé lorsque la requête retourne un ensemble de résultats dans un format XML. Par exemple, cet ensemble de résultats est utilisé pour une instruction SELECT qui comprend une clause FOR XML.

Si la tâche d'exécution SQL utilise l'ensemble de résultats Ensemble de résultats complet et que la requête retourne plusieurs ensemble de lignes, la tâche ne retourne que le premier. Si cet ensemble de lignes génère une erreur, la tâche la signale. En revanche, si d'autres ensembles de lignes génèrent des erreurs, la tâche ne les signale pas.

La tâche d'exécution SQL convertit en chaînes les valeurs retournées par l'instruction SQL qui ne sont pas déjà des chaînes. Par exemple, les valeurs de type de données SQL Server uniqueidentifier, bigint, decimal ou numeric sont converties en chaînes.

Remplissage d'une variable avec un ensemble de résultats

Vous pouvez lier l'ensemble de résultats retourné par une requête à une variable définie par l'utilisateur si le type de l'ensemble de résultats est une ligne unique, un ensemble de lignes ou XML.

Si le type de l'ensemble de résultats est Ligne unique, vous pouvez lier une colonne du résultat obtenu à une variable en utilisant le nom de colonne comme nom d'ensemble de résultats. Vous pouvez également utiliser comme nom la position ordinale de la colonne dans la liste des colonnes. Par exemple, le nom de l'ensemble de résultats de la requête SELECT Color FROM Production.Product WHERE ProductID = ? pourrait être Color ou 0. Si la requête retourne plusieurs colonnes et que vous souhaitez accéder aux valeurs de toutes les colonnes, vous devez lier chaque colonne à une variable différente. Si vous associez des colonnes à des variables en utilisant des numéros comme noms de jeux de résultats, ces numéros reflètent l'ordre d'apparition des colonnes dans la liste des colonnes de la requête. Par exemple, dans la requête SELECT Color, ListPrice, FROM Production.Product WHERE ProductID = ?, vous utilisez 0 pour la colonne Color et 1 pour la colonne ListPrice. La possibilité d'utiliser un nom de colonne comme nom d'ensemble de résultats dépend du fournisseur que la tâche a été configurée pour utiliser. Tous les fournisseurs ne rendent pas les noms de colonnes disponibles.

Certaines requêtes qui retournent une valeur unique peuvent ne pas inclure de noms de colonnes. Par exemple, l'instruction SELECT COUNT (*) FROM Production.Product ne retourne aucun nom de colonne. Vous pouvez accéder à l'ensemble de résultats en utilisant la position ordinale, 0, comme nom de résultat. Pour accéder au résultat de retour par nom de colonne, la requête doit inclure une clause AS <nom alias> pour fournir un nom de colonne. L'instruction SELECT COUNT (*)AS CountOfProduct FROM Production.Product, fournit la colonne CountOfProduct. Vous pouvez ensuite accéder à la colonne de résultat de retour en utilisant le nom de colonne CountOfProduct ou la position ordinale, 0.

Si le type de l'ensemble de résultats est Ensemble de résultats complet ou XML, vous devez utiliser 0 comme nom d'ensemble de résultats.

Lorsque vous associez une variable à un ensemble de résultatss à l'aide du type Ligne unique, la variable doit être d'un type de données compatible avec celui de la colonne contenue dans l'ensemble de résultats. Par exemple, vous ne pouvez pas associer un ensemble de résultats contenant un type de données String à une variable de type de données numérique. Un ensemble de résultats XML ne peut être associé qu'à une variable de type de données String ou Object. Si la variable est de type de données String, la tâche d'exécution SQL retourne une chaîne et la source XML peut exploiter les données XML. Si la variable est de type de données Object, la tâche d'exécution SQL retourne un objet DOM (Document Object Model). Un ensemble de résultats complet doit correspondre à une variable du type de données Object. Le résultat obtenu est un objet d'ensemble de lignes. Vous pouvez écrire des tâches personnalisées qui explorent l'objet d'ensemble de lignes et accèdent aux informations relatives aux colonnes et aux données de l'ensemble de lignes.

Le tableau suivant récapitule les types de données des variables pouvant correspondre à des ensembles de résultats.

Type d'ensemble de résultats	Type de données de la variable	Type d'objet
Ligne unique	Tout type compatible avec la colonne de type contenue dans l'ensemble de résultats.	Non applicable
Ensemble de résultats complet	Object	Si la tâche utilise un gestionnaire de connexions natif, tel que les gestionnaires de connexions ADO, OLE DB, Excel et ODBC, l'objet retourné est un Recordset ADO. Si la tâche fait appel à un gestionnaire de connexions managées, notamment le gestionnaire de connexions ADO.NET, l'objet retourné est un System.Data.DataSet.
XML	String	String
XML	Object	Si la tâche utilise un gestionnaire de connexions natif, tel que les gestionnaires de connexions ADO, OLE DB, Excel et ODBC, l'objet retourné est un MSXML6.IXMLDOMDocument. Si la tâche fait appel à un gestionnaire de connexions managées, notamment le gestionnaire de connexions ADO.NET, l'objet retourné est un System.Xml.XmlDocument.

Vous pouvez définir la variable dans la portée de la tâche d'exécution SQL ou dans celle du package. Si la portée de la variable est le package, l'ensemble de résultats est disponible pour les autres tâches et conteneurs figurant dans le package, ainsi que pour tout package exécuté par les tâches d'exécution de package ou d'exécution de package DTS 2000.

Lorsque vous mappez une variable à un jeu de résultats Ligne unique, les valeurs retournées par l'instruction SQL qui ne sont pas déjà des chaînes peuvent être converties en chaînes. C'est le type de gestionnaire de connexions utilisé qui détermine si cette conversion a lieu ou si cette conversion est implicite ou explicite.

Avec un gestionnaire de connexions ADO.NET, la conversion n'a pas lieu.
Avec un gestionnaire de connexions ADO ou ODBC, cette conversion a lieu implicitement.
Avec un gestionnaire de connexions OLE DB ou Excel, le gestionnaire de connexions convertit explicitement les valeurs de type DBTYPE_I8, DBTYPE_UI8, DBTYPE_NUMERIC, DBTYPE_GUID et DBTYPE_BYTES en chaînes.

Pour plus d'informations sur le chargement d'un ensemble de résultats dans une variable, consultez Procédure : mapper des ensembles de résultats à des variables dans une tâche d'exécution SQL.

Entrées de journal personnalisées disponibles dans la tâche d'exécution SQL

Le tableau suivant décrit les entrées de journal personnalisées de la tâche d'exécution SQL. Pour plus d'informations, consultez Implémentation de la journalisation dans les packages et Messages personnalisés pour la journalisation.

Entrée du journal	Description
ExecuteSQLExecutingQuery	Fournit des informations sur les phases d'exécution de l'instruction SQL. Des entrées de journal sont écrites lorsque la tâche acquiert la connexion à la base de données, lorsqu'elle commence à préparer l'instruction SQL et au terme de l'exécution de l'instruction SQL. L'entrée de journal concernant la phase de préparation inclut l'instruction SQL que la tâche utilise.

Résolution des problèmes liés à la tâche d'exécution SQL

À partir de Microsoft SQL Server 2005 Service Pack 2 (SP2), vous pouvez consigner les appels que la tâche d'exécution SQL effectue auprès des fournisseurs de données externes. Vous pouvez utiliser cette nouvelle fonctionnalité de journalisation pour résoudre des problèmes liés aux commandes SQL qu'exécute la tâche d'exécution SQL. Pour journaliser les appels que la tâche d'exécution SQL effectue vers un fournisseur de données externes, activez la journlisation des packages et sélectionnez l'événement Diagnostic au niveau du package. Pour plus d'informations, consultez Dépannage de l'exécution des packages.

Parfois, une commande SQL ou une procédure stockée retourne plusieurs jeux de résultats. Ces jeux de résultats ne comprennent pas seulement des ensembles de lignes qui sont le résultat de requêtes SELECT, mais aussi des valeurs uniques qui sont le résultat d'instructions RAISERROR ou PRINT. À l'exception du gestionnaire de connexions ODBC, tous les autres gestionnaires de connexions ignorent les jeux de résultats qui se produisent après le premier jeu de résultats. Par conséquent, ces gestionnaires de connexions ignorent une erreur retournée par une commande SQL ou une procédure stockée si l'erreur ne fait pas partie du premier jeu de résultats.

Configuration de la tâche d'exécution SQL

Vous pouvez définir les propriétés par programme ou par le biais du concepteur SSIS.

Pour plus d'informations sur les propriétés définissables dans le concepteur SSIS, cliquez sur l'une des rubriques suivantes :

Pour plus d'informations sur la définition de ces propriétés dans le concepteur SSIS, cliquez sur la rubrique suivante :

Comment : définir les propriétés des tâches

Configuration de la tâche d'exécution SQL par programme

Pour plus d'informations sur la définition par programme de ces propriétés, cliquez sur la rubrique suivante :

ExecuteSQLTask

Voir aussi

Historique des modifications

Version	Historique
15 septembre 2007	Contenu modifié : Erreurs corrigées dans la syntaxe des paramètres ODBC. Explication de la façon dont le mappage d'une variable à un jeu de résultats Ligne unique peut entraîner la conversion de certaines valeurs de retour en chaînes. Ajout d'informations sur la résolution des erreurs qui se produisent dans plusieurs jeux de résultats.
12 décembre 2006	Nouveau contenu : Ajout d'informations sur la manière dont SQL Server 2005 SP2 inclut de nouveaux messages de journalisation avec lesquels les utilisateurs peuvent résoudre les appels qu'effectue la tâche auprès de fournisseurs de données externes.
17 juillet 2006	Contenu modifié : Ajout d'un tableau d'entrées de journal personnalisées. Ajout à la table d'une colonne répertoriant les types d'objets que peut retourner un ensemble de résultats. Séparation des types de résultats d'objet et de chaîne XML.
14 avril 2006	Contenu modifié : Ajout d'une table indiquant les correspondances possibles entre les variables et les ensembles de résultats. Ajout d'informations sur la propriété BypassPrepare.
5 décembre 2005	Contenu modifié : Informations ajoutées sur l'exécution d'instructions SQL paramétrées.