We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 26903
    • 1,336 Posts
    Whats the best/preferred way of getting error info strings back from xPDO. I’m looking for an equivalent of the MYSQL function ’mysql_error’ so I can feed this back to the GUI. A bit of context, I’m calling the save() function on an element(template actually) that’s failing, the fail is ’template with that name already exists’ i.e. duplicate, this is OK, I just want to tell the user.
      Use MODx, or the cat gets it!
      • 22303 MODX Staff
      • 10,725 Posts
      Quote from: shamblett at May 31, 2010, 08:50 AM

      Whats the best/preferred way of getting error info strings back from xPDO. I’m looking for an equivalent of the MYSQL function ’mysql_error’ so I can feed this back to the GUI. A bit of context, I’m calling the save() function on an element(template actually) that’s failing, the fail is ’template with that name already exists’ i.e. duplicate, this is OK, I just want to tell the user.
      I don’t know what the best way is, but for the moment I know of three options:

      • Set the $xpdo->logTarget to an array reference (new feature), e.g.
      <?php
      $errors = array ();
      $xpdo->setLogTarget(array(
          'target' => 'ARRAY'
          ,'options' => array('var' => & $errors)
      ));
      ?>

      • Set the $xpdo->logTarget to a file or db register and you can read the errors across requests (this is what package installation does in MODx)
      • Check $xpdo->errorInfo() or $xpdo->errorCode(), which should contain information about the most recent error encountered by a PDOStatement or PDO itself.
      The problem with the first two is that there may be other internal log messages to deal with, and it’s not currently localizable. The final option you can check for specific error codes and display your own custom, even localized messages, specific to your purposes.
        • 26903
        • 1,336 Posts
        Ok, using this snippet of code :-

        if ($element->save() == false) {
                        $errorText = $element->xpdo->errorInfo();
                        $errorstring =  $errorText[0];
                        $errorstring .= " : " . $errorText[1];
                        $errorstring .= " : " . $errorText[2];
        


        I get this output ’00000 : : ’, this may be because of this from PHP :-
        PDO::errorInfo() only retrieves error information for operations performed directly on the database handle. If you create a PDOStatement object through PDO::prepare() or PDO::query() and invoke an error on the statement handle, PDO::errorInfo() will not reflect the error from the statement handle. You must call PDOStatement::errorInfo() to return the error information for an operation performed on a particular statement handle.

        If so I’ll file a bug, it would be handy to be able to do this.

          Use MODx, or the cat gets it!
          • 22303 MODX Staff
          • 10,725 Posts
          Quote from: shamblett at May 31, 2010, 01:51 PM

          Ok, using this snippet of code :-

          if ($element->save() == false) {
                          $errorText = $element->xpdo->errorInfo();
                          $errorstring =  $errorText[0];
                          $errorstring .= " : " . $errorText[1];
                          $errorstring .= " : " . $errorText[2];
          


          I get this output ’00000 : : ’, this may be because of this from PHP :-
          PDO::errorInfo() only retrieves error information for operations performed directly on the database handle. If you create a PDOStatement object through PDO::prepare() or PDO::query() and invoke an error on the statement handle, PDO::errorInfo() will not reflect the error from the statement handle. You must call PDOStatement::errorInfo() to return the error information for an operation performed on a particular statement handle.

          If so I’ll file a bug, it would be handy to be able to do this.


          Well, FWIW, this is going to change completely in the future to be exception-based and there is no way to solve this in xPDO currently. Use method 1 or 2 I provided. This is where the PDOStatement errorInfo is captured in the process currently.

          Otherwise, you can manually prepare and execute the xPDOCriteria/xPDOQuery objects (instead of calling getObject/getCollection) and check for the errorInfo on the xPDOCriteria::$stmt that will be available (that’s the PDOStatement). You’ll have to hydrate the objects manually though in that case.