| title | description | author | ms.author | ms.date | ms.service | ms.subservice | ms.topic | helpviewer_keywords | |||
|---|---|---|---|---|---|---|---|---|---|---|---|
Processing Stored Procedure Results |
Learn about the mechanisms SQL Server stored procedures use to return data to applications. Applications must be able to handle all these types. |
markingmyname |
maghan |
03/14/2017 |
sql |
native-client |
reference |
|
[!INCLUDESQL Server Azure SQL Database Synapse Analytics PDW]
[!INCLUDEssNoVersion] stored procedures have four mechanisms used to return data:
-
Each SELECT statement in the procedure generates a result set.
-
The procedure can return data through output parameters.
-
A cursor output parameter can pass back a [!INCLUDEtsql] server cursor.
-
The procedure can have an integer return code.
Applications must be able to handle all these outputs from stored procedures. The CALL or EXECUTE statement should include parameter markers for the return code and output parameters. Use SQLBindParameter to bind them all as output parameters and the [!INCLUDEssNoVersion] Native Client ODBC driver will transfer the output values to the bound variables. Output parameters and return codes are the last items returned to the client by [!INCLUDEssNoVersion]; they are not returned to the application until SQLMoreResults returns SQL_NO_DATA.
ODBC does not support binding [!INCLUDEtsql] cursor parameters. Because all output parameters must be bound before executing a procedure, any [!INCLUDEtsql] stored procedure that contains an output cursor parameter cannot be called by ODBC applications.