Appel d'une procédure stockée
Le pilote ODBC SQL Server Native Client prend en charge à la fois la séquence d'échappement ODBC CALL et l'instruction Transact-SQL EXECUTE pour exécuter des procédures stockées ; la séquence d'échappement ODBC CALL est la méthode recommandée. L'utilisation de la syntaxe ODBC permet à une application de récupérer les codes de retour de procédures stockées et le pilote ODBC SQL Server Native Client est également optimisé pour utiliser un protocole initialement développé pour envoyer des appels de procédure distante (RPC) entre des ordinateurs qui exécutent 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]
Lors de l'appel des procédures stockées SQL Server à l'aide de paramètres nommés avec ODBC (pour plus d'informations, consultez Liaison de paramètres par nom (paramètres nommés)), le nom des paramètres doit 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 MDAC (Microsoft Data Access Components).
La séquence d'échappement ODBC CALL permettant d'appeler une procédure est la suivante :
{[?=]call nom_procédure[([paramètre][,[paramètre]]...)]}
où nom_procédure spécifie le nom d'une procédure et 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ètres doivent être liés avec SQLBindParameter avant l'exécution de l'instruction d'appel de la 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. Exemple :
{call nom_procédure**( )**}
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. Exemple :
{call nom_procédure}
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
Le pilote ODBC SQL Server Native Client prend en charge par défaut également 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 des instructions CALL qui suivent les règles ISO et mettent chaque identificateur entre guillemets doubles :
{ CALL "master"."dbo"."sp_who" }
Lors d'une exécution avec les paramètres par défaut, toutefois, le pilote ODBC SQL Server Native Client ne prend pas en charge l'utilisation de l'une ou de l'autre forme d'identificateurs entre guillemets avec des identificateurs qui contiennent des caractères non spécifiés comme légaux dans des identificateurs définis par la norme ISO. Par exemple, le pilote ne peut pas accéder à une procédure stockée nommée "My.Proc" en utilisant 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] }