In addition to any rowsets they return, stored procedures MAY also return a return code, which is either an integer value or NULL. The calling application may have various ways of retrieving it; in T-SQL you can get it thus:

> In addition to any rowsets they return, stored procedures MAY also > return a return code, which is either an integer value or NULL. The > calling application may have various ways of retrieving it; in T-SQL > you can get it thus:

> > In addition to any rowsets they return, stored procedures MAY also > > return a return code, which is either an integer value or NULL. The > > calling application may have various ways of retrieving it; in T-SQL > > you can get it thus:

No, not at all. There are two conflicting meanings of "return" here. Only an integer can be a return *value*. But the stored procedure can also return -- better termed as "create", rather than return -- zero, one, OR MORE *rowsets* (which may or may not be related to each other). The two different things come by completely different paths.

The only way to capture a rowset that a stored procedure creates within T-SQL is by means of an INSERT statement:

INSERT someTable EXEC procedurename, param, param ...

And even in that case you can still capture the return value separately:

INSERT someTable EXEC @rtn=procedurename, param, param ...

To increase the amount of confusion, someTable can be a table-valued *variable* instead of a real table .... :-)