> My patch isn't quite correct. It sets the output parameters only as > long as there are zero or one record sets returned - two or more and > the parameters are not set. If we just always call > _mssql_get_sp_result then this problem will be avoided, but might > that cause some other issue?
I've played with this some more. You can't get the output parameters for the stored procedure call until after all the result sets have been read (a limit of the SQL Server DB-Library). The mssql_next_result() function is already set to do this, but you need to call it an extra time (i.e., if you have two result sets you have to call it once to get the second result set and then a second time to get the output parameters set). We definatley need to document this. I propose that my earlier patch is applied as it restored the BC that was broken in 4.3.0. In 4.2.3 the output parameters were always set after the call to mssql_execute(), but in 4.3.0 you now always have to call mssql_next_result() at least once. As a result any calls to mssql_execute() with output parameters in pre-4.3.0 code break when run under 4.3.0. With my patch if you have a stored procedure that returns one or no result sets the output parameters are returned just as they used to be. If you are returning multiple result sets (a new feature in 4.3.0) then you need to call mssql_next_result() an extra time to get the output parameters set correctly. Since that is a new feature there are no BC issues (just a need for a documention warning). Michael Sisolak [EMAIL PROTECTED] __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
