> 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
[EMAIL PROTECTED]


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
--- php_mssql.orig.c    Wed Jan 08 16:24:07 2003
+++ php_mssql.c Thu Jan 09 00:26:43 2003
@@ -2053,12 +2053,10 @@
                RETURN_FALSE;
        }
 
-       /* The following is just like mssql_query, fetch all rows from the server into 
-        *      the row buffer. We add here the RETVAL and OUTPUT parameters stuff
+       /* The following is just like mssql_query, fetch all rows from the first 
+result 
+        *      set into the row buffer. 
         */
        result=NULL;
-       /* if multiple recordsets in a stored procedure were supported, we would 
-          use a "while (retval_results!=NO_MORE_RESULTS)" instead an "if" */
        if (retval_results==SUCCEED) {
                if ( (retvalue=(dbnextrow(mssql_ptr->link)))!=NO_MORE_ROWS ) {
                        num_fields = dbnumcols(mssql_ptr->link);
@@ -2079,9 +2077,11 @@
                        result->statement = statement;
                }
        }
-       else if (retval_results==NO_MORE_RESULTS) {
-               _mssql_get_sp_result(mssql_ptr, statement TSRMLS_CC);
-       }
+       
+       /* Try to get output parameters.  Won't work if there are more record sets
+        *  in the batch until they are all retrieved with mssql_next_result().
+        */
+       _mssql_get_sp_result(mssql_ptr, statement TSRMLS_CC);
        
        if (result==NULL) {
                RETURN_TRUE;    /* no recordset returned ...*/

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to