Bug 143851 - PEAR DB parses prepare() statements incorrectly
PEAR DB parses prepare() statements incorrectly
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: php (Show other bugs)
3
i586 Linux
medium Severity medium
: ---
: ---
Assigned To: Joe Orton
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-12-29 20:18 EST by Rodrigo Damazio
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version: 4.3.11-2.4
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-04-19 03:53:49 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Rodrigo Damazio 2004-12-29 20:18:46 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)
Gecko/20040922

Description of problem:
When using the prepare() command of the DB object from PEAR, the
statement is parsed incorrectly, and '?' components are not identified.
When debugging thruogh PEAR's source, I found the error to be created
on line 990 of DB/comon.php. The cause for this appears to be in line
780 of the same file, where print_r($tokens) shows the expected
contents for $tokens (an array of strings), however the simple code:

foreach ($tokens as $t) echo $t;

gives me "Array Array Array Array Array" (for a 5-component query)
This is a rather weird behavior, which may indice an internal PHP bug.
Also, previous version(4.3.9-3) had the exact same code for this
function, and worked perfectly, indicating that the problem may not be
in PEAR itself.

Version-Release number of selected component (if applicable):
php-4.3.10-3.2

How reproducible:
Always

Steps to Reproduce:
1. Execute the following, changing the query and database DSN to a
database you already have:
<?
    require_once('DB.php');
 
    // Convenience debug function
    function db_check_pretty_die($o) {
        if (DB::isError($o)) {
            die('<BR><span style="color: red;">'
                .' <span style="font-weight: bold;">Error
message:</span> '.$o->getMessage().'<BR>'
                .' <span style="font-weight: bold;">User info:</span>
'. $o->getUserInfo().'<BR>'
                .'</span><BR><BR>'
                .'<span style="font-size: 16px; font-weight:
bolder;">Backtrace:</span><BR>'
                .'<pre>'.print_r(debug_backtrace(),true).'</pre>');
        }
    }
 
    // Connect to database
    $dsn = "pgsql://user:pass@/db";
    $db = DB::connect($dsn, true);
    db_check_pretty_die($db);
    $db->setFetchMode(DB_FETCHMODE_ASSOC);
                                                                     
          
    // This is where the incorrect values are detected
    $st = $db->prepare('SELECT * FROM data WHERE iddatum=? AND hidden=?');
    $data = array(1234, false);
     
    // This is where the error is reported, when count($data) doesn't
match
    //the number of detected question marks
    $res = $db->execute($st, $data);
    db_check_pretty_die($res);
    $row = $res->fetchRow();
 
?>

Actual Results:  The following output was shown:
-------------
Error message: DB Error: mismatch
User info: Array Array Array Array Array


Backtrace:

Array
(
    [0] => Array
        (
            [file] => /var/www/html/test.php
            [line] => 28
            [function] => db_check_pretty_die
        )

)
-----------


Expected Results:  The query should be executed and a row should be
retrieved from the result set.

Additional info:

Didn't happen in 4.3.9-3.
Comment 1 Joe Orton 2005-04-19 03:53:49 EDT
Should be fixed in the 4.3.11 update, thanks for the report:

http://www.redhat.com/archives/fedora-announce-list/2005-April/msg00033.html

  

Note You need to log in before you can comment on or make changes to this bug.