Take the 2-minute tour ×

I have a massive site I inherited built using Zend Framework. It's a internal company site and many employees have been complaining of errors. The last guy only ever gave a response of "It's working fine for me", hence why he was fired.

I went through and did some research and found I could make a error handle controller. So I created one that captured all the errors and I have been fixing them as they come up (and I now see why the guy as saying it works fine for me, cause the employee's were screwing up on somethings and the guy just didn't have the logic programmed in to handle those screw ups).

Right now I'm done to just a few "Invalid parameter number: no parameters were bound" errors, I have the stack trace's so I do know what line is causing the error. I also have the GET and POST values. Some of the points where it's causing a throwing this error have a lot of logic leading up to it. So I'm wondering if there is a way From the Zend_Controller_Plugin_ErrorHandler if I can retrieve the SQL statement that was being run.

I know I could wrap the calls and catch them independently, but that wont help future problems that come up. Any insight into this would be greatly appreciated.

share|improve this question
add comment

2 Answers

If you are on PHP 5.3, try getting the previous exception from the exception that you have.

If not, use Zend_Db_Profiler and log the queries and then retrieve them all in the error controller. You'll probably have to manually match up to the error though.

share|improve this answer
the previous exception did not work, but the Zend_Db_Profiler did work though it created problems. It slowed the system down by 5seconds to 1min in some sections. So I had to disable the profiler. –  Pyromanci Apr 18 '12 at 19:44
I'm surprised it slows you down that much as it doesn't do a lot! However, in that case, you're left with monkey patching the Zend_DB code. Find the line of code where the exception is called and add a log at that point to store whatever you can in the context of that particular piece of code. –  Rob Allen Apr 19 '12 at 4:57
add comment
up vote 0 down vote accepted

Based around what Rob said,

I went in and modified the Zend_Db_Exception class. and added

public $_stmt = null;

Then in the Zend_Db_Statement_Exception class I changed the __construct to this:

 * @param string $message
 * @param string|int $code
 * @param Exception $chainedException
     * @param Statment i.e. Query String
public function __construct($message = null, $code = null, Exception $chainedException=null, $_stmt = null)
    $this->message = $message;
    $this->code = $code;
    $this->_chainedException = $chainedException;
        $this->_stmt = $_stmt;

Then in the Zend_Db_Statement_Pdo class I change all the

throw new Zend_Db_Statement_Exception($e->getMessage(), $e->getCode(), $e);


throw new Zend_Db_Statement_Exception($e->getMessage(), $e->getCode(), $e, $this->_stmt);

Then in side my Zend_Controller_Plugin_ErrorHandler action, I have this leading it off.

    switch ($errors->type) {
        case "EXCEPTION_NO_ROUTE":
        case "EXCEPTION_NO_ACTION":
            // 404 error -- controller or action not found
            $this->view->title = "Page Not Found";
            $this->view->title = "Unknown Error";

    $sql = null;
    $offending_query = null;
    $exception = $errors->exception;
        $offending_query = $exception->_stmt->queryString;
    catch (Zend_Exception $e)
    {   }

With this change to the Zend DB core I'm now able to capture all my offending SQL statements with zero impact to performance unlike profiler was.

share|improve this answer
add comment

Your Answer


