Re (4): SQL Stored Procedure return value

Your initial answer only showed retrieving multiple result sets -- the ... was leaving out something important, which your later example showed.

And I stand by my statement: DBD::Sybase makes output parameters appear to be part of a result set, but in fact they are handled differently by the SQL Server API.

Comment on Re (4): SQL Stored Procedure return value

Replies are listed 'Best First'.
Re: Re (4): SQL Stored Procedure return value by mpeppler (Vicar) on Jul 17, 2003 at 20:18 UTC
And I stand by my statement: DBD::Sybase makes output parameters appear to be part of a result set, but in fact they are handled differently by the SQL Server API Actually that's not quite true. DBD::Sybase simply uses the Client Library API, which in turn uses the TDS protocol. For TDS 4.2 and 5 OUTPUT parameters are returned as a normal result set (although it's a CS_PARAM_RESULT result set, instead of a CS_ROW_RESULT result set). I believe that MS changed things somewhat in TDS 7 and 8 (at least that's what I think I've read on the FreeTDS mailing list). TDS 4.2 is the protocol level that was spoken by MS-SQL 4.2, which was originally Sybase SQL Server 4.2. TDS 5 is spoken by Sybase versions 10 and later. TDS 7 is MSSQL 7, TDS 8 is MSSQL 2K. Michael	[reply]
Re: Re (4): SQL Stored Procedure return value by derby (Abbot) on Jul 17, 2003 at 18:42 UTC
Hmmm ... it's just semantics and perspective .. wether you consider output parameters part of a multiple result set or not. They're definetly not part of the CS_ROW_RESULT set but they are part of the CS_PARAM_RESULT set which given the implementation of DBD::Sybase will be returned with the basic fetch loop. Sure I left out the detailed spefics but there was enough information in the node (linkage to docs, key verbage - syb_result_type) for the user to find out the info. Sorry, just my style of "teaching to fish" instead of "giving a fish". -derby.	[reply]