Fwd: Re: [BUGFIX 21089/21328] MSSQL not returning values of SP output parameters in 4.3.0

> 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). Okay, I've really _got_ to stop responding to myself multiple times. People may begin to wonder... It turns out there was an issue with my first patch attempt as it left the state of the database result set pointer incorrect if there were multiple record sets. The attached patch fixes this by always trying to get the output parameters without first testing if there is another result set that will block the request. Nothing bad happens if there is, and if there isn't the output parameters are correctly set. I couldn't find a way to peak ahead to see if there was another result set so that I could skip this, but it doesn't seem to do any harm. This patch now makes mssql_execute() work for output parameters from a stored procedure with zero and one result sets just as it did in 4.2.3, and for 2+ result sets requires calls to mssql_next_result(). Michael Sisolak msisolak@yahoo.com __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com