Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 1.12.1

Doc Bug #12057 Non-static method DB::isError() should not be called static
Submitted: 2007-09-16 01:36 UTC
From: brycenesbitt Assigned:
Status: Bogus Package: DB (version 1.7.12)
PHP Version: 5.2.4 OS: Linux
Roadmaps: (Not assigned)    
Subscription  


 [2007-09-16 01:36 UTC] brycenesbitt (Bryce Nesbitt)
Description: ------------ The documentation for PEAR::DB seems to encourage this type of construct: $db = DB::Connect($dsn); if (DB::isError($db)) { die($db->message.'<br>'.$db->userinfo); } $db->setOption('optimize', 'portability'); Which under php5 is resulting in the following errors/warnings: General PHP error : Non-static method DB::isError() should not be called statically General PHP error : Non-static method DB::Connect() should not be called statically Test script: --------------- require_once(PEAR_PATH.'DB.php'); $dsn = array( 'phptype' => DB_TYPE, 'hostspec' => DB_HOST, 'database' => DB_DATABASE, 'username' => DB_USER, 'password' => DB_PASSWORD ); $db = DB::Connect($dsn); if (DB::isError($db)) { die($db->message.'<br>'.$db->userinfo); } $db->setOption('optimize', 'portability'); $db->setFetchMode(DB_FETCHMODE_ASSOC); $db->setErrorHandling(PEAR_ERROR_CALLBACK, "handle_db_error"); Expected result: ---------------- No errors. A lot of the PEAR::DB documentation states on the net specifically states: Note: This function should be called statically. And "Return: whether $value is DB_Error object". Neither sentence is clear. This at least deserves a FAQ entry, if not a fix. Fiddling with E_STRICT is not a good solution. Actual result: -------------- General PHP error : Non-static method DB::isError() should not be called statically General PHP error : Non-static method DB::Connect() should not be called statically

Comments

 [2007-09-16 01:42 UTC] brycenesbitt (Bryce Nesbitt)
If you google for this, you'll find a lot of people have this problem. There's all sorts of speculation as to why, and all sorts of bogus (non-working or hacky) solutions.
 [2007-09-16 05:10 UTC] aharvey (Adam Harvey)
Thank you for taking the time to write to us, but this is not a bug. PEAR DB isn't E_STRICT compatible, nor will it be at any point, since it has to retain compatibility with PHP4.
 [2007-09-16 05:50 UTC] brycenesbitt (Bryce Nesbitt)
All I'm saying here is -- it's confusing. Would you put it in the FAQ? I'm not saying it's a bug that directly needs fixing. Google it, and you'll see plenty of people confused by this. You folks, with access to the documentation, can make this point clear. ------------------------------------------------------ I've modified the project I was working on to: $db = new DB(); $db = $db->Connect($dsn); if ($db->isError($db)) { die($db->message.'<br>'.$db->userinfo); }
 [2007-09-16 16:11 UTC] brycenesbitt (Bryce Nesbitt)
Please note I'm not complaining about an obscure warning in some log file. I can't run jpgraph without a fix or workaround to this issue.
 [2007-09-16 19:17 UTC] berdir (Sascha Grossenbacher)
Disable E_STRICT error messages, for example with: error_reporting(E_ALL); As Adam has said, this is not a bug, DB can't be E_STRICT compatible, a change would break PHP4-compatibility
 [2007-09-17 03:30 UTC] brycenesbitt (Bryce Nesbitt)
I'm not asking you to make DB strict compatible. And fiddling with the error level solution solved the problem, I'd never have bothered reporting this. It's not that easy, especially when the error level is set by a module you are calling. Setting E_STRICT as you propose DOES NOT SOLVE THE PROBLEM in the project I'm working on. And never mind php6 where E_ALL and E_STRICT are... I think... the same. The PEAR::DB documentation and FAQ say nothing of this issue, no matter how simple or complex the solution may be. Lots of people run into it. If you have a solution, why not add a FAQ entry, or document it? I'm currently having reasonably good luck getting JPGraph to work, without having to hack JPGraph itself, with: $db = new DB(); $db = $db->connect($dsn); if ($db->isError($db)) { die($db->message.'<br>'.$db->userinfo); } If you google you'll find one of the most common "solutions" is to hack DB.php and add the static keyword. Is that how the Pear::DB maintainers would suggest that it be done?
 [2007-09-17 11:16 UTC] aharvey (Adam Harvey)
No, I'd suggest that the assumption not be made that PEAR DB is in any way E_STRICT compliant. I'm not going to endorse any sort of hack to work around an issue that, frankly, isn't one. Re-closing.
 [2007-09-18 02:04 UTC] brycenesbitt (Bryce Nesbitt)
Who said DB is supposed to be E_STRICT compatible? DB is however, supposed to be usable -- just consider how frustrating it is to use the package, run into this error, discover lots of people run into this error, but have no recourse to find an "approved" solution, or even an approved description of the issue. It's not like the error message is self-explanatory or anything.
 [2009-11-04 21:28 UTC] wstein (William Steinford)
I fully agree with brycenesbitt that there needs to be better documentation about this warning message. This is not specific to PEAR DB, but to much of PEAR... it needs to be clearer that PEAR is not PHP5 E_STRICT compatible... There's a clear amount of arrogance here in asserting "This is a bogus problem because PEAR is not E_STRICT compatible". ...Since PEAR is not E_STRICT compatible, IT SHOULD BE VERY EASY TO LEARN THAT PEAR IS NOT E_STRICT COMPATIBLE. Therefore, it should be properly documented.
 [2012-05-23 10:08 UTC] connect2maddy (Mani kandan)
Is anyone solved that issue? Made lots and lots of searches about this issue and dint find anything good and still the error exists. Please help to solve this issue.