Which other API's are you talking about?  Oracle?  It's the only other extension that uses fetch into really.

As for the statement, there is no way for ODBC to really tell either.  The API itself defines this to be rather ambiguous so it becomes difficult to deal with.  At this time the result leaves it to the PHP user to decide if one is really an emtpy string or NULL rather than the PHP engine.  I tend to think this is a better solution.  

What I meant is that every SQL based PHP database API has a function to fetch rows into an array. When it is not not *_fetch_into is *_fetch_row.

I do not see any ambiguity in figuring if a result column has a NULL. As a matter of fact in the current odbc_function of php_odbc.c you have:

http://cvs.php.net/co.php/php4/ext/odbc/php_odbc.c?r=1.143.2.1

if (result->values[i].vallen == SQL_NULL_DATA) {
	Z_STRVAL_P(tmp) = empty_string;
	break;
}

Since NULL is always NULL regardless of the data type of a column, all that needs to be done is to leave undefined (NULL) the respective column position of the PHP array value returned by the odbc_fetch_into.

Try a snapshot dated sometime after this.  I believe it does what you want/desire.  If not many complaints happen I'll leave it in... 

I just tried Win32 build of PHP 4.4.0-dev taken from snaps.php.net (php4-win32-200301062330.zip) and it is working the same. It looked like the fix would solve the problem but it works as if the fix was not applied. Isn't that build supposed to include the fix?

It should contain it.  You can look into the code though and see for yourself just to ensure.  The fix is in the points that you suggested, but if it's not working I'm not sure what to tell you other than wait.  

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.

Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.

This bug still happening, the solution is here in this diff. Please commit it because I do not have enough karma to do it myself.

Hope This Helps,

Ernani Joppert Pontes Martins


Index: php_odbc.c
===================================================================
RCS file: /repository/php4/ext/odbc/php_odbc.c,v
retrieving revision 1.153
diff -c -r1.153 php_odbc.c
*** php_odbc.c	24 Jan 2003 22:40:38 -0000	1.153
--- php_odbc.c	7 Feb 2003 01:38:46 -0000
***************
*** 1589,1595 ****
  				if (rc == SQL_SUCCESS_WITH_INFO) {
  					Z_STRLEN_P(tmp) = result->longreadlen;
  				} else if (result->values[i].vallen == SQL_NULL_DATA) {
! 					Z_STRVAL_P(tmp) = IS_NULL;
  					break;
  				} else {
  					Z_STRLEN_P(tmp) = result->values[i].vallen;
--- 1589,1595 ----
  				if (rc == SQL_SUCCESS_WITH_INFO) {
  					Z_STRLEN_P(tmp) = result->longreadlen;
  				} else if (result->values[i].vallen == SQL_NULL_DATA) {
! 					ZVAL_NULL(tmp);
  					break;
  				} else {
  					Z_STRLEN_P(tmp) = result->values[i].vallen;
***************
*** 1599,1605 ****
  
  			default:
  				if (result->values[i].vallen == SQL_NULL_DATA) {
! 					Z_STRVAL_P(tmp) = IS_NULL;
  					break;
  				}
  				Z_STRLEN_P(tmp) = result->values[i].vallen;
--- 1599,1605 ----
  
  			default:
  				if (result->values[i].vallen == SQL_NULL_DATA) {
! 					ZVAL_NULL(tmp);
  					break;
  				}
  				Z_STRLEN_P(tmp) = result->values[i].vallen;

commited.