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

Bug #7856 Error messages are not precise
Submitted: 2006-06-10 15:17 UTC
From: reg at dav-muz dot net Assigned: lsmith
Status: Closed Package: MDB2 (version 2.0.3)
PHP Version: Irrelevant OS: irrelevant
Roadmaps: (Not assigned)    
Subscription  
Comments Add Comment Add patch


Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know! Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem : 9 + 11 = ?

 
 [2006-06-10 15:17 UTC] reg at dav-muz dot net (Davide Muzzarelli)
Description: ------------ Error messages are not precise. If I commit an error that is not in the query but in the PHP function, the error message refer to the previous query and not in the actual. Error messages should be precise and could refer to the correct error. Test script: --------------- Example (debug mode active): 1: [...] // do a correct query without errors (aka Query1). 2: 3: // do a second correct query (aka Query2). 4: $prep = array($query2, array('inteeeegggeeerrrr')); // <- there is an error: integer! 5: $result = $prep->execute(array(10)); 6: if (MDB2::isError($result)) { 7: print_r($result->getMessage() . ' ' . $result->getUserInfo()); 9: } Expected result: ---------------- Output: the Query2 has an error at line 7! Actual result: -------------- Output: the Query1 has an error at line 7!

Comments

 [2006-06-11 14:16 UTC] lsmith (Lukas Smith)
This bug has been fixed in CVS. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better. I presume you were using one of the backends where prepared statements were emulated? Unfortunately there is really know semantically consistent solution here. The problem is that the real query has not yet been constructed. I will therefore set the last_query to the prepared statement. This will be overwritten with the final query later on in the method.
 [2006-06-12 10:49 UTC] reg at dav-muz dot net
> I presume you were using one of the backends where > prepared statements were emulated? Yes, I use MySQL 4.x and it is partially emulated. I think that the query have not to be the message (the query is correct), but the real problem: a function parameter is invalid. However, your fix can solve hours of debugging, THX!