Home » Database » DB » Bug #2166

[2004-08-19 21:37 UTC] dtd at skybuilders dot com

Description:
------------
Greetings,

We have recently installed php5 (5.0.1) on Fedora Core 2. We have upgraded Pear (1.3.2) and DB (1.6.5) to their latest versions.
Here is our configure string:
Configure Command => './configure' '--host=i386-redhat-linux' '--build=i386-redhat-lin
ux' '--target=i386-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix
=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/sh
are' '--includedir=/usr/include' '--libdir=/usr/lib' '--libexecdir=/usr/libexec' '--loc
alstatedir=/var' '--sharedstatedir=/usr/com' '--mandir=/usr/share/man' '--infodir=/usr/
share/info' '--cache-file=../config.cache' '--with-config-file-path=/etc' '--with-confi
g-file-scan-dir=/etc/php.d' '--enable-force-cgi-redirect' '--disable-debug' '--enable-p
ic' '--disable-rpath' '--enable-inline-optimization' '--with-bz2' '--with-db4=/usr' '--
with-curl' '--with-exec-dir=/usr/bin' '--with-freetype-dir=/usr' '--with-png-dir=/usr'
'--with-gd' '--enable-gd-native-ttf' '--without-gdbm' '--with-gettext' '--with-ncurses'
'--with-gmp' '--with-iconv' '--with-jpeg-dir=/usr' '--with-openssl' '--with-png' '--wi
th-regex=system' '--with-xml' '--with-expat-dir=/usr' '--with-dom=shared,/usr' '--with-
dom-xslt=/usr' '--with-dom-exslt=/usr' '--with-xmlrpc=shared' '--with-pcre-regex=/usr'
'--with-zlib' '--with-layout=GNU' '--enable-bcmath' '--enable-exif' '--enable-ftp' '--e
nable-magic-quotes' '--enable-safe-mode' '--enable-sockets' '--enable-sysvsem' '--enabl
e-sysvshm' '--enable-track-vars' '--enable-trans-sid' '--enable-yp' '--enable-wddx' '--
with-pear=/usr/share/pear' '--with-imap=/usr/local/imap-2004a' '--with-kerberos' '--wit
h-ldap=shared' '--with-mysql=shared,/usr' '--with-pgsql=shared,/usr' '--with-unixODBC=s
hared,/usr' '--enable-memory-limit' '--enable-bcmath' '--enable-shmop' '--enable-calend
ar' '--enable-dbx' '--enable-dio' '--enable-mcal' '--enable-mbstring' '--enable-mbstr-e
nc-trans' '--enable-mbregex' '--with-apxs2=/usr/sbin/apxs' '--with-mhash' '--with-tidy'
'--with-mcrypt' '--with-pcre=/usr' '--enable-simplexml' '--enable-soap' '--with-xsl' '
--with-libxml-dir=/usr'
In a test page, we have connected successfully to a PostgreSQL data source. Upon making queries of that connection, we find that while we are able to successfully make INSERTs and UPDATEs, SELECTs do not return an object of type "db_result", rather an integer 1. Why is this? There seems to be no result. An identical request through the PostgreSQL client psql produces a good example recordset containing the three records that are in the table "test" (which consists of a single column
of type integer called "id").
Our code seems to match the examples in the end-user documentation, so this would appear to be a possible bug. Extensive searches for possible explanations has only led us to the suspicion that it may be related to php5's new OO return only by reference architecture. A post to the pear-dev mailing list got back a suggestion to report this issue as a bug. Please advise.

Thanks very much for your help.

--
Derek Doyle, VP/CIO
http://www.skyBuilders.com
77 Huron Avenue
Cambridge, MA 02138-6707
617 876-5675

Reproduce code:
---------------
# $sPassword has been properly set above
$oDBConnection =& DB::connect('pgsql://gemini:' . $sPassword .
'@127.0.0.1:5432/gemini', array('debug' => 1));

echo('connection error: ' . DB::iserror($oDBConnection) . '<br />');
echo('connection test: ' . DB::isconnection($oDBConnection) . '<br />');
if (DB::iserror($oDBConnection)) {
echo('DB Error!<br />');
$sDBError = $oDBConnection->getMessage();
}

# this insert works properly
# $sSQLQuery = 'INSERT INTO test (id) VALUES (345);';
# $oResult =& $oDBConnection->query($sSQLQuery);

# this select does not
$sSQLQuery = 'SELECT * FROM test;';
$oResult =& $oDBConnection->query($sSQLQuery);

echo('result: ' . $oResult . '<br />');
echo('error: ' . DB::iserror($oResult) . '<br />');
# echo('error message: ' . $oResult->errormessage() . '<br />');
if (DB::iserror($oResult)) {
# . "<br />sSQLQuery: " . $sSQLQuery
die("<br />Error: " . $oResult->getMessage() . "<br />Details: "
. $oResult->getDebugInfo());
}

echo('string: ' . is_string($oResult) . '<br />');
echo('integer: ' . is_integer($oResult) . '<br />');
echo('array: ' . is_array($oResult) . '<br />');
echo('class: ' . get_class($oResult) . '<br />');

$sCount = $oResult->numRows();
echo('count: ' . $sCount);

if ($sCount) {
$oTest = $oResult->fetchRow(DB_FETCHMODE_ASSOC);
$sID = $oTest['id'];
}
echo('id: ' . $sID);

Expected result:
----------------
connection error:
connection test: 1
result: array()
error:
string:
integer:
array:
class: db_result
count: 3
id: 123

Actual result:
--------------
connection error:
connection test: 1
result: 1
error:
string:
integer: 1
array:
class:

Fatal error: Call to a member function numRows() on a non-object in
/var/www/gemini.skybuilders.com/index.html on line 44

[2004-08-20 19:25 UTC] dtd at skybuilders dot com

Thanks for the quick response!

I'm almost certain that it's something wrong on my end. However, it isn't clear to me what.

I like your test approach very much. I put your test script in place of mine, and changed the name of my connection variable to $db. The output now looks like:

Fatal error: Call to a member function fetchRow() on a non-object in /var/www/gemini.skybuilders.com/php-bug.html on line 20

After removing the table test2166 manually (since the error above blocked the script's DROP) through psql, I pasted in my reporting lines and adapted them for the name $res. The output now reads:

result: 1
error:
string:
integer: 1
array:
class:

Fatal error: Call to a member function fetchRow() on a non-object in /var/www/gemini.skybuilders.com/php-bug.html on line 33

In essence, your cleaner test has the same outcome as our original test on our system. It is informative to find that the CREATE command also works properly.

Thanks.

[2004-08-21 04:14 UTC] dtd at skybuilders dot com

I set the error reporting to E_ALL, the connect() debug option to 2, and added your test for DB_Result right after the connection string.
Here is the current output:

Warning: preg_match: internal pcre_fullinfo() error -3 in /usr/share/pear/DB.php on line 604
Warning: preg_match: internal pcre_fullinfo() error -3 in /usr/share/pear/DB.php on line 632
DB_result found
Warning: preg_match: internal pcre_fullinfo() error -3 in /usr/share/pear/DB.php on line 471
Warning: preg_match: internal pcre_fullinfo() error -3 in /usr/share/pear/DB/pgsql.php on line 186
Warning: preg_match: internal pcre_fullinfo() error -3 in /usr/share/pear/DB.php on line 471
Warning: preg_match: internal pcre_fullinfo() error -3 in /usr/share/pear/DB/pgsql.php on line 186
Warning: preg_match: internal pcre_fullinfo() error -3 in /usr/share/pear/DB.php on line 471
Warning: preg_match: internal pcre_fullinfo() error -3 in /usr/share/pear/DB/pgsql.php on line 186
result: 1
error:
string:
integer: 1
array:
class:
Fatal error: Call to a member function fetchRow() on a non-object in /var/www/gemini.skybuilders.com/php-bug2.html on line 39

End of output.

Apparently DB_Result is found. I find that include_path is not set in /etc/php.ini. Should it be? We had assumed that since it seemed to find DB.php and make the connection to the database, that things were being included properly.
I did a Google search for those warnings about pcre_fullinfo(), but found only an open PHP bug "#29158 Warning with preg_match". This is only a warning; can this be safely ignored, or is it related?

[2004-08-23 19:37 UTC] dtd at skybuilders dot com

Indeed! Quite bogus! Sorry for the inconvenince and thank you for your attention.

A recompile using the bundled pcre libs (by removing "--with-pcre-regex=/usr" and "--with-pcre", and changing "--with-regex=system" to "--withregex=php") solved the problem. The tests now work and a DB_Result object is returned.

Thanks again.