php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #61516 PDOStatement::errorInfo returning NULL for driver code and message
Submitted: 2012-03-26 16:49 UTC Modified: 2014-01-01 12:39 UTC
Votes:1
Avg. Score:4.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:0 (0.0%)
Same OS:0 (0.0%)
From: julien at palard dot fr Assigned:
Status: Open Package: PDO MySQL
PHP Version: 5.4.0 OS: Linux 2.6.32-5-amd64
Private report: No CVE-ID:
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: julien at palard dot fr
New email:
PHP Version: OS:

 

 [2012-03-26 16:49 UTC] julien at palard dot fr
Description:
------------
While using not emulated prepared statement against MySQL 5.5, warnings (using ERRMODE_WARNING) are more verbose than errorInfo(). With prepared queries, errorInfo return (string, NULL, NULL).

This fact is true with or without ERRMODE_WARNING.

And this fact is also true, but different while using standard queries :

What the warning give me :
{{{
[WARNING] PDO::query() [<a href='pdo.query'>pdo.query</a>]: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '83-27
7727' for key 'UNIQUE'
}}}

What I got from errorInfo()[2] (Missing the "Integrity constraint violation:" string, built client side from error code ?) :
{{{
Duplicate entry '83-277727' for key 'UNIQUE'
}}}



Test script:
---------------
<?php

class My_PDOStatement extends PDOStatement
{
    public function execute($input_parameters = NULL)
    {
        $res = parent::execute($input_parameters);
        if ($res === FALSE)
            var_dump($this->errorInfo());
        return $res;
    }
}

$options = array(PDO::ATTR_PERSISTENT => FALSE,
                 PDO::ATTR_ERRMODE => PDO::ERRMODE_WARNING,
                 PDO::ATTR_EMULATE_PREPARES => FALSE,
                 PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_ASSOC,
                 PDO::ATTR_STATEMENT_CLASS => array('My_PDOStatement'));

$pdo = new PDO(...);

$stmt = $pdo->prepare("SELECT :a + :a");
$stmt->execute(array('a' => 1)); // Willingly generate 'Invalid parameter number'
var_dump($stmt->fetchAll());


Expected result:
----------------
I Expect errorInfo() to return error messages.

Actual result:
--------------
errorInfo() in this specific case return (string, NULL, NULL).

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2012-04-30 16:39 UTC] uw@php.net
The PDO warning is based on a static look-up table compiled into the PDO core. That means, it is out of control of any PDO driver. A SQL code reported by a driver is translated into whatever message the PDO core likes.

Any PDO driver is free to provide an internal callback to update the contents of the return value of errorInfo(). Providing an internal callback is not mandatory.

Due to the different source of the error message one must not expect error messages to be equal. At the end of the day: this is PDO...
 [2012-05-02 09:51 UTC] julien at palard dot fr
uw@php.net, I think that one can expect to have as much as possible informations about an error, and that it's not fair to provide different level of precision to one querying the error description from one way.

Just think about those who just didn't spotted the difference or those who simply don't want to use ERRMODE_WARNING, they will have harder times to fix their SQL bugs, that's not a good thing. I personally think this should be fixed.
 [2014-01-01 12:39 UTC] felipe@php.net
-Package: PDO related +Package: PDO MySQL
 
PHP Copyright © 2001-2017 The PHP Group
All rights reserved.
Last updated: Tue Aug 29 15:01:52 2017 UTC