Note also that this same exact script continues to run without problems under PHP 4.1.2 on a Debian 3.0 (potato) box. This box has DB2 V7.1 installed.

> Source code unlikely to be useful 
Well, just "something goes wrong here" is unlikely to be useful either. We need to know at least how to reproduce it, as we cannot fix something that we don't see.
So please provide short and complete reproduce script (that doesn't require any non-existent tables, stored procedures etc.), i.e. we should be able to copy/paste it and reproduce your problem.

Okay,

A test script which drives the problem is included below. You must modify the script to supply credentials for accessing your own IBM DB2 database. REMINDER: This bug only started happening after our iSeries DB2 database host was upgraded to the latest release (V5R4).

The script references the table SYSIBM.SQLTYPEINFO which I believe should be a standard system table in the IBM DB2 database. If this table does not exist in your installation, you should be able to adapt the script to use virtually any table that does. The choice of table does not seem to have a bearing on whether or not the bug occurs.

The following error message is produced when the script is run:

"PHP Fatal error:  Allowed memory size of 524288000 bytes exhausted (tried to allocate 1835295024 bytes) in /home/www-devel/htdocs/admin/db2test.php on line 40"

Note that the test script below *does* work under PHP 4.1.2 on a Debian 3.0 (potato) box with DB2 V7.1 installed and which talks to the same iSeries DB2 database server.

***** Start of test script *****
<?
//
// Script to drive excessive memory allocation bug when using ODBC 
// (--with-ibm-db2) to talk to DB2 database.
//
session_start();

// Init error messages
$errmsg = "";
$odbc_errmsg = "";

// Open database connection
$db2_dsn = "<your_dsn>";
$db2_user = "<your_username>";
$db2_passwd = "<your_password>";

$db2_conn = odbc_connect($db2_dsn, $db2_user, $db2_passwd);
if (!$db2_conn) {
  $errmsg = "Connection to database failed!";
}

// Start building SQL SELECT query based on input parameters
$db2_query = "select * from sysibm.sqltypeinfo";

// Do query for selecting matching records.
if ($errmsg == "") {
  user_error("About to do query: [$db2_query]"); // DEBUG!!!!!
  $db2_result = odbc_exec($db2_conn, $db2_query);

  if (!$db2_result) {
    $errmsg = "<h2>Database query failed!</h2>\n";
    $odbc_errmsg = odbc_errormsg($db2_conn);
    if ($odbc_errmsg) {
      $errmsg .= "<p>$odbc_errmsg";
    }
  }
}

while (odbc_fetch_row($db2_result)) {
  $col1 = odbc_result($db2_result, 1);
  $col2 = odbc_result($db2_result, 2);
  $col3 = odbc_result($db2_result, 3);
  $col4 = odbc_result($db2_result, 4);
  $col5 = odbc_result($db2_result, 5);

  print "$col1, $col2, $col3, $col4, $col5<br>\n";
} // while (odbc_fetch_row(...))

// Close database connection
if ($db2_conn) {
  odbc_close($db2_conn);
}

?>
***** End of test script *****

Please try using this CVS snapshot:

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

For Windows (installer):

  http://snaps.php.net/win32/php5.2-win32-installer-latest.msi

And try with the PDO ODBC driver instead.

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".