Llamar a un procedimiento almacenado
Se aplica a:
SQL Server Azure SQL Database Azure SQL Instancia administrada Azure Synapse Analytics Analytics Platform System (PDW)
El controlador ODBC de SQL Server Native Client admite la secuencia de escape ODBC CALL y la instrucción EXECUTE de Transact-SQLpara ejecutar procedimientos almacenados; la secuencia de escape ODBC CALL es el método preferido. El uso de la sintaxis ODBC permite a una aplicación recuperar los códigos de retorno de los procedimientos almacenados y el controlador ODBC de SQL Server Native Client también está optimizado para usar un protocolo desarrollado originalmente para enviar llamadas a procedimientos remotos (RPC) entre equipos que ejecutan SQL Server. Este protocolo RPC aumenta el rendimiento eliminando gran parte del procesamiento de parámetros y análisis de instrucciones que se realiza en el servidor.
Nota:
Al llamar a procedimientos almacenados de SQL Server mediante parámetros con nombre con ODBC (para obtener más información, vea Binding Parameters by Name (Named Parameters)), los nombres de parámetro deben comenzar con el carácter '@'. Se trata de una restricción específica de SQL Server. El controlador ODBC de SQL Server Native Client aplica esta restricción más estrictamente que los componentes de Microsoft Data Access (MDAC).
La secuencia de escape ODBC CALL para llamar a un procedimiento es:
{[?=]callprocedure_name[([parameter][,[parameter]]...)]}
donde procedure_name especifica el nombre de un procedimiento y un parámetro especifica un parámetro de procedimiento. Los parámetros con nombre solo se admiten en instrucciones que utilizan la secuencia de escape ODBC CALL.
Un procedimiento puede tener cero o más parámetros. También puede devolver un valor (que se indica con el marcador de parámetro opcional ?= al inicio de la sintaxis). Si un parámetro es de entrada o de entrada/salida, puede ser un literal o un marcador de parámetro. Si el parámetro es de salida, debe ser un marcador de parámetro porque se desconoce la salida. Los marcadores de parámetro deben enlazarse con SQLBindParameter antes de ejecutar la instrucción de llamada a procedimiento.
Los parámetros de entrada y de entrada/salida pueden omitirse de las llamadas a procedimiento. Si se llama a un procedimiento con paréntesis pero sin ningún parámetro, el controlador indica al origen de datos que use el valor predeterminado para el primer parámetro. Por ejemplo:
{call procedure_name( )}
Si el procedimiento no tiene ningún parámetro, puede producirse un error en el procedimiento. Si se llama a un procedimiento sin paréntesis, el controlador no envía ningún valor de parámetro. Por ejemplo:
{call procedure_name}
Pueden especificarse literales para los parámetros de entrada y de entrada/salida en llamadas a procedimiento. Por ejemplo, el procedimiento InsertOrder tiene cinco parámetros de entrada. La siguiente llamada a InsertOrder omite el primer parámetro, proporciona un literal para el segundo parámetro y usa un marcador de parámetro para el tercero, cuarto y quinto parámetro. (Los parámetros se numeran secuencialmente, comenzando por el valor 1.)
{call InsertOrder(, 10, ?, ?, ?)}
Tenga en cuenta que aunque se omita un parámetro, la coma que lo separa de los demás parámetros debe estar presente. Si se omite un parámetro de entrada o de entrada/salida, el procedimiento usa el valor predeterminado del parámetro. Otras formas de especificar el valor predeterminado de un parámetro de entrada o de entrada/salida consisten en establecer el valor del búfer de longitud/indicador enlazado al parámetro en SQL_DEFAULT_PARAM, o bien, usar la palabra clave DEFAULT.
Si se omite un parámetro de entrada/salida, o si se proporciona un literal para el parámetro, el controlador descarta el valor de salida. Del mismo modo, si se omite el marcador de parámetro para el valor devuelto de un procedimiento, el controlador descarta dicho valor devuelto. Finalmente, si una aplicación especifica un parámetro de valor devuelto para un procedimiento que no devuelve ningún valor, el controlador establece el valor del búfer de longitud/indicador enlazado al parámetro en SQL_NULL_DATA.
Delimitadores en instrucciones CALL
El controlador ODBC de SQL Server Native Client de forma predeterminada también admite una opción de compatibilidad específica de la secuencia de escape ODBC { CALL } . El controlador acepta instrucciones CALL con un solo conjunto de comillas dobles que delimitan el nombre del procedimiento almacenado completo:
{ CALL "master.dbo.sp_who" }
De forma predeterminada, el controlador ODBC de SQL Server Native Client también acepta instrucciones CALL que siguen las reglas ISO y incluyen cada identificador entre comillas dobles:
{ CALL "master"."dbo"."sp_who" }
Sin embargo, cuando se ejecuta con la configuración predeterminada, el controlador ODBC de SQL Server Native Client no admite el uso de ninguna forma de identificador entre comillas con identificadores que contienen caracteres no especificados como legales en los identificadores por el estándar ISO. Por ejemplo, el controlador no puede acceder a un procedimiento almacenado denominado "My.Proc" mediante una instrucción CALL con identificadores entre comillas:
{ CALL "MyDB"."MyOwner"."My.Proc" }
El controlador interpreta esta instrucción como:
{ CALL MyDB.MyOwner.My.Proc }
El servidor genera un error que indica que no existe un servidor vinculado denominado MyDB .
Este problema no ocurre si se usan identificadores entre paréntesis; la instrucción se interpreta correctamente:
{ CALL [MyDB].[MyOwner].[My.Table] }