Llamar a un procedimiento almacenado
El controlador ODBC de SQL Server Native Client admite la secuencia de escape ODBC CALL y la instrucción EXECUTE de Transact-SQL para ejecutar procedimientos almacenados; la secuencia de escape ODBC CALL es el método preferido. El uso de la sintaxis ODBC permite que una aplicación recupere 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 originalmente desarrollado para enviar llamadas a procedimiento remoto (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 utilizando parámetros con nombre con ODBC (para obtener más información vea Enlazar parámetros por nombre (parámetros con nombre)https://go.microsoft.com/fwlink/?LinkID=209721), los nombres de los parámetros deben empezar c on el carácter '@'. Se trata de una restricción específica de SQL Server. El controlador ODBC de SQL Server Native Client exige esta restricción de una manera más estricta que Microsoft Data Access Components (MDAC).
La secuencia de escape ODBC CALL para llamar a un procedimiento es:
{[?=]callnombre_procedimiento[([parámetro][,[parámetro]]...)]}
donde nombre_procedimiento especifica el nombre de un procedimiento y 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ámetros deben enlazarse a SQLBindParameter para poder 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 nombre_procedimiento**( )**}
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 nombre_procedimiento}
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
De forma predeterminada, el controlador ODBC de SQL Server Native Client 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 e incluyen cada identificador entre comillas dobles:
{ CALL "master"."dbo"."sp_who" }
No obstante, cuando el controlador ODBC de SQL Server Native Client se ejecuta con la configuración predeterminada no admite el uso de cualquier forma de identificador entrecomillado con identificadores que contienen caracteres no especificados como legales en identificadores por el estándar ISO. Por ejemplo, el controlador no puede obtener acceso a un procedimiento almacenado denominado "My.Proc" mediante una instrucción CALL con identificadores entrecomillados:
{ 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] }