[Reposted for entry into the nifty new bug database]

We've been calling stored procedures in MS-SQL thusly:

  $result = odbc_exec($conn,"exec sp_asp_dmsGetArtist 303");

That has worked up to and including 3.0b2a.  However in
more recent versions, including 3.0b4-dev, that code has 
produced:

  Warning:  Function SQLExecDirect in testodbc.php3 on line 22
  Warning:  SQL error: [Microsoft][ODBC SQL Server Driver]Cursor type 
            changed, SQL state 01S02 in testodbc.php3 on line 22

According to ODBC docs:

  SQLSTATE:  01S02
  Error:  Option value changed
  Description:  The driver did not support the specified
                value of the vParam argument and
                substituted a similar value. (Function
                returns SQL_SUCCESS_WITH_INFO.)

By comparing the 3.0b2a and 3.0b3-dev unified_odbc.c files,
we've located the probable cause of this error.  In
php3_uodbc_do() on line 763 (in 3.0b3-dev) we see:

  if(SQLSetStmtOption(result->stmt, SQL_CURSOR_TYPE, SQL_CURSOR_DYNAMIC)
     != SQL_SUCCESS){

That function call appears to complete successfully.  Then,
on line 776 we see:

  if((rc = SQLExecDirect(result->stmt, query, SQL_NTS)) != SQL_SUCCESS){

It is this function that appears to generate the error.  My
guess is that our ODBC driver doesn't support SQL_CURSOR_DYNAMIC
and falls back to the default cursor type (which works fine
in 3.0b2a).  The query then completes successfully (according
to SQLTrace), and returns SQL_SUCCESS_WITH_INFO (according to
ODBC doc quote above).

Based on this information, I believe the fix is to replace 
line 776 with:

  rc = SQLExecDirect(result->stmt, query, SQL_NTS);
  if (rc != SQL_SUCCESS && rc != SQL_SUCCESS_WITH_INFO) {