Appel d’une procédure stockée
S’applique à :
SQL Server Azure SQL Database Azure SQL Managed Instance Azure Synapse Analytics Analytics Platform System (PDW)
Le pilote ODBC SQL Server Native Client prend en charge la séquence d’échappement ODBC CALL et l’instruction Transact-SQLEXECUTE pour l’exécution de procédures stockées ; la séquence d’échappement ODBC CALL est la méthode préférée. L’utilisation de la syntaxe ODBC permet à une application de récupérer les codes de retour des procédures stockées et le pilote ODBC SQL Server Native Client est également optimisé pour utiliser un protocole développé à l’origine pour envoyer des appels de procédure distante (RPC) entre ordinateurs exécutant SQL Server. Ce protocole RPC augmente les performances en supprimant une bonne partie du traitement des paramètres et de l'analyse des instructions sur le serveur.
Remarque
Lorsque vous appelez des procédures stockées SQL Server à l’aide de paramètres nommés avec ODBC (pour plus d’informations, consultez Paramètres de liaison par nom (paramètres nommés)), les noms de paramètres doivent commencer par le caractère « @ ». Il s'agit d'une restriction spécifique à SQL Server. Le pilote ODBC SQL Server Native Client applique cette restriction plus strictement que les composants MDAC (Microsoft Data Access Components).
La séquence d'échappement ODBC CALL permettant d'appeler une procédure est la suivante :
{[ ?=]callprocedure_name[([parameter][,[parameter]]...)]}
où procedure_name spécifie le nom d’une procédure et d’un paramètre spécifie un paramètre de procédure. Les paramètres nommés sont pris en charge uniquement dans les instructions à l'aide de la séquence d'échappement ODBC CALL.
Une procédure peut avoir zéro, un ou plusieurs paramètres. Elle peut également retourner une valeur (comme l'indique le marqueur de paramètre optionnel ?= au début de la syntaxe). Si un paramètre est un paramètre d'entrée ou d'entrée/sortie, ce peut être un littéral ou un marqueur de paramètre. Si le paramètre est un paramètre de sortie, ce doit être un marqueur de paramètre car la sortie est inconnue. Les marqueurs de paramètre doivent être liés à SQLBindParameter avant l’exécution de l’instruction d’appel de procédure.
Les paramètres d'entrée et d'entrée/sortie peuvent être omis dans les appels de procédure. Si une procédure est appelée avec des parenthèses mais sans paramètre, le pilote instruit la source de données d'utiliser la valeur par défaut comme premier paramètre. Par exemple :
{call procedure_name( )}
Si la procédure n'a pas de paramètre, elle peut échouer. Si une procédure est appelée sans parenthèses, le pilote n'envoie aucune valeur de paramètre. Par exemple :
{call procedure_name}
Des littéraux peuvent être spécifiés comme paramètres d'entrée et d'entrée/sortie dans les appels de procédure. Par exemple, la procédure InsertOrder possède cinq paramètres d'entrée. L'appel suivant à InsertOrder omet le premier paramètre, fournit un littéral pour le deuxième paramètre et utilise un marqueur de paramètre pour les troisième, quatrième et cinquième paramètres. (Les paramètres sont numérotés de façon séquentielle, en commençant par la valeur 1.)
{call InsertOrder(, 10, ?, ?, ?)}
Notez que si un paramètre est omis, la virgule qui le sépare des autres paramètres doit encore apparaître. Si un paramètre d'entrée ou d'entrée/sortie est omis, la procédure utilise la valeur par défaut du paramètre. D'autres façons de spécifier la valeur par défaut d'un paramètre d'entrée ou d'entrée/sortie consistent à affecter la valeur SQL_DEFAULT_PARAM à la mémoire tampon de l'indicateur/longueur associée au paramètre ou à utiliser le mot clé DEFAULT.
Si un paramètre d'entrée/sortie est omis ou si un littéral est fourni comme paramètre, le pilote ignore la valeur de sortie. De la même façon, si le marqueur de paramètre pour la valeur de retour d'une procédure est omis, le pilote ignore la valeur de retour. Enfin, si une application spécifie un paramètre de valeur de retour pour une procédure qui ne renvoie pas de valeur, le pilote affecte la valeur SQL_NULL_DATA à la mémoire tampon de l'indicateur/longueur associée au paramètre.
Délimiteurs dans les instructions CALL
Par défaut, le pilote ODBC SQL Server Native Client prend également en charge une option de compatibilité spécifique à la séquence d’échappement ODBC { CALL } . Le pilote accepte les instructions CALL avec un jeu unique de guillemets doubles délimitant le nom complet de la procédure stockée :
{ CALL "master.dbo.sp_who" }
Par défaut, le pilote ODBC SQL Server Native Client accepte également les instructions CALL qui suivent les règles ISO et placent chaque identificateur entre guillemets doubles :
{ CALL "master"."dbo"."sp_who" }
Lors de l’exécution avec les paramètres par défaut, toutefois, le pilote ODBC SQL Server Native Client ne prend pas en charge l’utilisation d’une forme d’identificateur entre guillemets avec des identificateurs qui contiennent des caractères non spécifiés comme légaux dans les identificateurs par la norme ISO. Par exemple, le pilote ne peut pas accéder à une procédure stockée nommée « My.Proc » à l’aide d’une instruction CALL avec des identificateurs entre guillemets :
{ CALL "MyDB"."MyOwner"."My.Proc" }
Cette instruction est interprétée par le pilote comme :
{ CALL MyDB.MyOwner.My.Proc }
Le serveur génère une erreur indiquant qu’un serveur lié nommé MyDB n’existe pas.
Ce problème ne se pose pas lors de l'utilisation d'identificateurs entre parenthèses et l'instruction suivante est interprétée correctement :
{ CALL [MyDB].[MyOwner].[My.Table] }