I have the same problem, this is related to the 4.3.8.

To resolve for now, I'm using the mssql.dll extension from the 4.3.7 with the 4.3.8 with out problems.

In the Zend Debugger now I see the nulls like null, no like " " with the 4.3.8 version.

I hope that this litte trick can be usefull meanwhile.

I've been having the same problem with 4.3.8.  I swapped php_mssql.dll with versions from 4.3.7, 4.3.6, 4.3.5, 4.3.4, and 4.3.3.  The space problem went away at 4.3.3 only.

I'm experiencing the same problem with the latest CVS of PHP5 and no php_mssql.dll extensions from older versions are compatable with PHP5.

Hi.

Following script ...

<?php

$rConn = mssql_connect('localhost','PHPBB_User','PHPBB_User');
$rResults = mssql_query('SELECT user_icq,LEN(user_icq) AS user_icq_len FROM PHPBB_User.phpbb_users');
while ($row = mssql_fetch_assoc($rResults))
	{
	var_export($row);
	echo '<br />Length of user_icq = ' . strlen($row['user_icq']) . '<br /><br /><br />';
	}
mssql_free_result($rResults);
mssql_close($rConn);
?>


produces output of ...

array ( 'user_icq' => ' ', 'user_icq_len' => 0, )
Length of user_icq = 1


array ( 'user_icq' => '1711757', 'user_icq_len' => 7, )
Length of user_icq = 7


array ( 'user_icq' => ' ', 'user_icq_len' => 0, )
Length of user_icq = 1


Which is clearly wrong! The length being returned by SQL is 0, the data being returned by PHP is ' '. The data via enterprise manager is ''.

I'm using Sambar Server V6.1 Beta 3, PHP V5.0.0 (about to upgrade to V5.0.1). MS SQL 2000 SP3 Developer Edition all on a Windows XP Pro. But none of this seems to be making any difference. According to all the comments made, this was broken a LONG time ago.

It seems that a small patch HAS been applied to the source (php_mssql.c line 793-797), but is under a compiler directive of ilia_0. (Is this Ilia Alshanetsky? If so, great article in PHP|Architect about contexts!!!).

The code is in the php_mssql_get_column_content_with_type() function.

...
		case SQLTEXT: {
			int length;
			char *data = charcol(offset);

			length=dbdatlen(mssql_ptr->link,offset);
#if ilia_0
			while (length>0 && data[length-1] == ' ') { /* nuke trailing whitespace */
				length--;
			}
#endif
			ZVAL_STRINGL(result, data, length, 1); 
			break;
		}
...

The macro ZVAL_STRINGL is ...

#define ZVAL_STRINGL(z, s, l, duplicate) {	\
		char *__s=(s); int __l=l;		\
		(z)->value.str.len = __l;	    \
		(z)->value.str.val = (duplicate?estrndup(__s, __l):__s);	\
		(z)->type = IS_STRING;		    \
	}


If someone can recompile the code, can they do so WITHOUT the directive first but put in some debugs (forget thread safeness, only testing) and show what the value of length in the assignment from dbdatlen(mssql_ptr->link,offset) and what happens if the macro is called with a 0 rather than a 1.

Hi.

If the column contains NULL (using Enterprise Manager to enter CTRL+0), then the output is correct.

But having to convert all '' to NULLs is not right.

Richard.

PHP 4.3.8

I am experiencing the same problem with non-empty string returned by a query that should return an empty string.

I have tried to replace the php_mssql.dll file in version 4.3.8 with the one from 4.3.3, but the problem remains with no change whatsoever:(

If there is someone familiar with PHP sources, does the php_mssql.c 1.138 revision changes deal with this bug, or it is something completely unrelated? And also, if the 'illia_0' change (pointed out by richard dot quadling at bandvulc dot co dot uk) effectively removes this bug (does it?), why is it then if'd out?

Thanks,
Viktor

I confirm this problem, under Windows 2003 Server, with Apache 2 or 1.3 and PHP 4.3.8 or 5.0.

The only way is to go back to PHP 4.3.3 ...
Not the good solution for me.
Do you know if someone is working on this bug to fix it?

We can adapt our product and trim() any variable to recover good values, but is it the good solution?..

Thank you for your help!

David

ilia introduced this bug on 1.86.2.25 fixing #25777.

all the meaning was discussed there. in the bottom line make sure php use updated ntwdblib.dll file.

> in the bottom line make sure php
> use updated ntwdblib.dll file.

Thanks momo. I've read #25777 and I understand that there are problems with PHP using older libraries to talk to SQL Server. 

I have ntwdblib.dll versions 7.00.839 (this is the one that ships with PHP including 4.3.9RC3) and 8.00.194 (which comes with SQL 2000) and the problem described in this bug shows up with both those libs. Is there an even newer version that I should be using?

If have installed php version 4.3.8 and 5.0 but with both versions some sort of the same problem is comming up. When i select all records from a View stored in MS SQL 2000 ("SELECT * FROM View_name) i get all the records while the view on SQL server is definied as SELECT * FROM Table WHERE field IS NOT NULL. When i run this last query in my query analyser the result is less records then when i start the view query with my php application. 

I think this has something to do with this same problem.

Winfred

I too have the same problem when upgrading to 4.3.8. 
 I did notice that using PEAR:DB functions the problem not longer happens.

Have you checked that the database is has a compatibility level >= 70? (see sp_dbcmptlevel)

Peter

This is clearly a bug in mssql dll. The sp_dbcmptlevel change the way an empty string is stored in sql but it has nothing to do with the fact that even a field that has not been updated with empty string still "is seen" as a single character by the mssql library. If you use ADO from VB, VC etc you get empty string. If you run from Query Analyzer |select 'x' + field + 'x' from table| you get |xx| not |x x| as mssql is returning. I am using PHP5 MSSQL2000 and the code is not working as it was with PHP4.0.6 and MSSQL97. Any help will be apreciated.
Thanks

I'm the original submitter, and just wanted to note that if you switch to using the PHP ADODB library from http://adodb.sourceforge.net/ you can choose several more up-to-date methods of connecting to SQL Server (e.g. via an OLEDB provider) that don't involve using the old ntwdblib.dll file and don't expose related bugs and limitations (such as the 256 character VARCHAR limit on SELECT). Works well with PHP5 too.