Please try using this CVS snapshot:

  http://snaps.php.net/php5-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5-win32-latest.zip

I tried http://snaps.php.net/win32/php5-win32-latest.zip (5.1.0RC2-dev). This yields the same results.

Frank, can you check this out?

This also happens for me in PHP 4.4.0 build of MSSQL.dll.

I also have the problem using 5.0.3 and a combination of PEAR's LiveUser using DB.

It can be reproduced with a 
$db =& DB::connect($dsn, $options);
var_dump($db->query('INSERT INTO liveuser_users_seq (vapor) VALUES (0)'));

extension of PHP 4.4.x (mssql.dll) = SQL Server 2000

extension of PHP 4.3.x (mssql.dll) = SQL Server 7

Corrected

I have this same issue on PHP 4.3.11(running as CGI) on Windows2000 server.

Happens intermittently.  Only pattern seems to be that it is when SQL Server is running a bit slower.

I'm running into this same issue with large result sets. 

I am running a Debian ETCH server with Apache2/PHP5.2
dpkg --list | grep "php" 
ii  libapache2-mod-php5               5.2.0-8+etch4                   server-side, HTML-embedded scripting languag
ii  php-pear                          5.2.0-8+etch4                   PEAR - PHP Extension and Application Reposit
ii  php5-cli                          5.2.0-8+etch4                   command-line interpreter for the php5 script
ii  php5-common                       5.2.0-8+etch4                   Common files for packages built from the php
ii  php5-curl                         5.2.0-8+etch4                   CURL module for php5
ii  php5-gd                           5.2.0-8+etch4                   GD module for php5
ii  php5-ldap                         5.2.0-8+etch4                   LDAP module for php5
ii  php5-mcrypt                       5.2.0-8+etch4                   MCrypt module for php5
ii  php5-mysql                        5.2.0-8+etch4                   MySQL module for php5
ii  php5-snmp                         5.2.0-8+etch4                   SNMP module for php5
ii  php5-sybase                       5.2.0-8+etch4                   Sybase / MS SQL Server module for php5

The exact error I am seeing is
Query: SELECT * FROM L_U_t_State WHERE Status='1' (51 Rows returned)
Error: Changed database context to 'RMS'.

Complexity or speed of query doesn't appear to matter, my larger multi-table selects/joins/unions do not produce the same error. 

PHP Code that is producing the error message
<?php
/* Run the query*/
$result = mssql_fetch_assoc($result_resource);

                if (!$result) { 
                        debug_event('num_rows','Failed: ' . $sql .  mssql_get_last_message(),'1'); 
                } 

?>


-Karl Vollmer

I am seeing this error on *every* MSSQL query under PHP 5.2.2, on Windows 2003 Server x64, in the apache 2.2.4 error log file.

Hi , 
I've written this code to use the data stored in the data-base named moviesite. The result is supposed to print the names of three different movies each one time.But,I get each 51 times I couldn't get where the error is present.So,please help me in rectifying my mistake......



<?php

//connecting to mysql
$connect = mysql_connect ( "localhost" , "root" , "") 
                   or die ( " You can't be connected to the server " ) ;
 
mysql_select_db (moviesite) ; 

$result = "SELECT movie_name , movie_year " . 
                "FROM movie " . 
                "WHERE movie_year > 1900 " . 
                "ORDER BY movie_name " ; 

$res = mysql_query ( $result ) 
                 or die ( mysql_error ( ) ) ; 


$st = 0 ; 

while( $ress = mysql_fetch_assoc ( $res ) )
{
 extract ( $ress ) ;
  echo "$movie_name" ; 
  echo "<br>" ; 
 $st = $st+1 ; 
}

echo "Finally the number of times it is printed is....".$st ; 

?>

This bug has not been fixed and it's driving me absolutely nuts as I can not seem to reproduce it in a non-production environment to find a workaround. It happens on UPDATEs, INSERTs, SELECTs, etc., and it's completely random.

I don't know if it's a PHP issue or a PEAR issue, but as of PHP 5.2.5 and PEAR 1.7.2 the so-called informative message of "Changed database context to ..." is still appearing. OS is Windows Server 2k3 and database is MS SQL Server 2005.


The following settings are used in php.ini:
===========================================
mssql.min_error_severity = 10
mssql.min_message_severity = 10


Here is some example code:
==========================
$sSql = 'UPDATE Table SET iNumber = 5 WHERE iRecordId = 666';
if (PEAR::isError($oResults = $rDbConn->query($sSql))) {
     die($oResults->getMessage());
}


Typical output would be:
========================
[Native code: 0]
[Native message: Changed database context to 'TableName'.]


Is this ever going to get fixed?

I was getting this error with a long running query and modified the php.ini to the following:

; Minimum error severity to display.
mssql.min_error_severity = 0

; Minimum message severity to display.
mssql.min_message_severity = 17


It's possible that lower settings could work as well...

This Bug is driving me crazy man, I am using
RHEL 5
Apache 2.0 server handler
Mysql 5.0
And trying to install PHP5.3.5 
installed all necessary file, now i use to connect to MSSQL server, my script 
shows
DB connected
DB selected

while performing Query it return "Changed database context XXXXXXX"
i have checked the same query on below two and running perfect
1. MSSQL terminal running file
2. Ran same script with all settings except PHP version 4.3.2 and 5.1.6

I tried the with RPM's as well but no luck. Googled a lot but no solution for 
the same.

Same problem but I found a valid solution to SP cases
Problem:
$proc = mssql_init("SP_Test");
mssql_bind($proc,"@var1",$_POST['var1'],SQLVARCHAR);
mssql_bind($proc,"@var2",$_POST['var2'],SQLVARCHAR);
$res = mssql_execute($proc) or die("ERROR: ".mssql_get_last_message());
//Output: Changed database context to 'DBNAME'

Solution:
$res = mssql_query("EXEC SP_Test '".$_POST['var1']."','".$_POST['var2']."'");

With MSSQL being removed from PHP as of PHP7.0, and ext/mssql not having a maintainer, I'm gonna close this report as a Won't fix, until maybe one day it will find a new maintainer.

Alternatively you can use sqlsrv from Microsoft if you are on Windows, or pdo_dblib if you are on Unix.