Bug #18966
closed
PHP Warning, if a sql error occurs - Bug in class t3lib_db function sql_fetch_assoc
0%
Description
mysql_fetch_assoc(): supplied argument is not a valid MySQL result resource in /pfad/typo3/t3lib/class.t3lib_db.php on line 796
This error occurs because the SQL select has an error. But it would be better if such PHP Errors does not occurs all the time. Here the fix in the file /t3lib/class.t3lib_db.php on line 796
/**
* Returns an associative array that corresponds to the fetched row, or FALSE if there are no more rows.
* mysql_fetch_assoc() wrapper function
* Usage count/core: 307
*
* @param pointer MySQL result pointer (of SELECT query) / DBAL object
* @return array Associative array of result row.
*/
function sql_fetch_assoc($res) {
if($this->debug_check_recordset($res)){
return mysql_fetch_assoc($res);
} else {
return false;
}
}
instead of the original code:
---------------------------------------
/**
* Returns an associative array that corresponds to the fetched row, or FALSE if there are no more rows.
* mysql_fetch_assoc() wrapper function
* Usage count/core: 307
*
* @param pointer MySQL result pointer (of SELECT query) / DBAL object
* @return array Associative array of result row.
*/
function sql_fetch_assoc($res) {
$this->debug_check_recordset($res);
return mysql_fetch_assoc($res);
}
I think, when the check function debug_check_recordset is used, the return value should be interpreted.
(issue imported from #M8728)
Files
Updated by Jonas Felix almost 16 years ago
This is a realy anyoing "bug" which leads to a lot of PHP Errors because of SQL Errors within Extensions. There is a devLog call instead of debug_check_recordset so this should be enough to alert the developers...
By the way what's the guideline about devLog, is this something we should use or not?
Updated by Sonja Schubert almost 16 years ago
It would be very great, if the bug could be fixed in the next version, because there are unnecessarily php warnings because of this bug. Would that be possible?
Updated by Franz Holzinger over 15 years ago
This is indeed an unnecessary PHP error output which should be avoided.
Updated by Franz Holzinger over 15 years ago
In TYPO3 4.2.3 I get these PHP error lines:
[15-Jan-2009 11:10:43] PHP Warning: mysql_query() [<a href='function.mysql-query'>function.mysql-query</a>]: Unable to save result set in /path/t3lib/class.t3lib_db.php on line 231
[15-Jan-2009 11:10:43] PHP Warning: mysql_fetch_assoc(): supplied argument is not a valid MySQL result resource in /path/t3lib/class.t3lib_db.php on line 809
[15-Jan-2009 11:10:43] PHP Warning: mysql_free_result(): supplied argument is not a valid MySQL result resource in /path/t3lib/class.t3lib_db.php on line 836
Updated by Franz Holzinger over 15 years ago
The patch to avoid all this useless PHP error messages has been added now to the extension debug_mysql_db 0.2.1.
Just install this extension to get rid of them in all cases and still see the SQL debug output.
Updated by Oliver Hader over 15 years ago
- the mentioned extension overrides t3lib_DB and thus disables any disposal of the DBAL
- the mentioned extension defines the queries to the repository again and does not use the existing methods (or does not wrap them, whatever)
The "mysql_fetch_assoc(): supplied argument is not a valid MySQL..." is a PHP warning and not a error. The mentioned output has a meaning. Something in a extension is wrong. Supressing the warning does not solve it at all. Sorry, that's not a solution at all.
If you'd like to know where the MySQL misbehaviour comes from, please go to the install tool, all configuration and enable the SQL Debug mode. Then you'll know what's wrong in the installed extension...
Updated by Oliver Hader over 15 years ago
A solution would be a proper error handling that also catches these warnings defines a general handling for it. However, there is not possibility to solve bugs in external extensions automatically... but I think we all knew this before... ;-)
Updated by Franz Holzinger over 15 years ago
DBAL: class ux_t3lib_DB extends t3lib_DB
debug_mysql_db: class ux_t3lib_DB extends t3lib_DB
- Yes, debug_mysql_db cannot be used together with DBAL. But how should this be programmed otherwise? DBAL as a system extension should not be written in a way that it uses an XCLASS itself. Hooks would be the way to go. Couldn't DBAL be rewritten to base on hooks?
I do not agree that the "mysql_fetch_assoc(): supplied argument is not a valid MySQL..." necessarliy means that there is a failure in an extension. This warning won't help anything, because it does not tell anything about the SQL query which went wrong nor anything about the file and the line of code where it had happend. This info does not help at all, It costs a lot of additional time for investigations. So either do not show it or give all details.
Yes, there is already the mysql-debug for this. So the PHP warning should not be shown any more, because it does not show the details.
Updated by Steffen Kamper over 15 years ago
I myself had this error a lot while develop. And - of coarse it doesn't help.
All the time i had to enable sqlDebug to see the reason.
This can't work with any live site, so this is bad. i suggest:
with disabled sqlDebug make a devlog entry with the failing SQL and catch the error in DBclass.
Updated by Sonja Schubert almost 15 years ago
I agree with Steffen.
I think, a devlog entry with the failing sql instead of the PHP error would be a good solution.
Who has the authorization to do this change? Who can do this?
Updated by Jonas Felix almost 15 years ago
I realy like sqlDebug :-), but the php error it selve should be catched. This is very easy if you check the mysql ressource befor using it with another myslq function like mysql_fetch_assoc...
Updated by Michiel Roos over 14 years ago
debug_check_recordset should only be called if debugging is enabled.
Updated by Felix Oertel over 14 years ago
Problem still existing in 4.2 and trunk.
Updated by Rupert Germann over 14 years ago
FYI: committed attached v2 to
trunk rev 6147
4_2 branch rev 6149
this fixes also bug #21270