TYPO3 Core

I had the same problem in the following situation. As my customer had a temporary technical problem with his ISP, I started developing his website in a subdirectory of my own domain. My ISP offers MySQL version 5.0.22 (and PHP verrsion 4.4.2). Everything runs fine.
After moving to my customer's domain, this problem ("not a valid MySQL result") keeps occurring. Customer's ISP (one of the biggest over here... ;-) uses MySQL version 4.1.18-log (whatever that "log"may mean.. - elsewhere they say that MySQL Client is version 4.1.14). Their PHP is version 4.4.0.

Please note that the problem occurs with the OLDER MySQL version. So it is unlikely to be a matter of a newer version being less tolerant.

I dislike to "mask" error messages with the "@" as long as I do not exaclty know what they are about. Has anyone a clue?

Real protection and FALSE on miss':

$res = $GLOBALS['TYPO3_DB']->exec_SELECTquery(
  'content', 'cache_hash',
  'hash='.$GLOBALS['TYPO3_DB']->fullQuoteStr($hash, 'cache_hash').
  $whereAdd
);
if ($res!==FALSE && $row = $GLOBALS['TYPO3_DB']->sql_fetch_assoc($res))    {
  $GLOBALS['TYPO3_DB']->sql_free_result($res);
  return is_array($row) ? $row['content'] : FALSE;
}

If nothing is selected, mysql does not return false, it returns empty recordset, see docs! It returns false only if query has errors.

mysql_fetch_assoc also returns false if there're no more rows: http://php.net/mysql_fetch_assoc

closed as it doesn't seem to be a bug

Reopened because the point was that the Core doesn't use @ to avid warnings in some places (and should check the result of SQL queries better).

Ingo, please don't close bugs. We're resolving them, so the bug submitter may reopen them. Old resolved bugs are closed in mass closings when a new version of TYPO3 is released.

Had the same problem (shown at top of the BE-Extension-Manager) after upgrading the source of a packet (Yaml).
The concerned functions are sql_fetch_assoc($res) and sql_free_result($res).

Inside the functions I wrapped "if ($res) { ... }" around the function-content and could solve the problem at least skin deep.

In general the Warning can occure in nearly every function of t3lib, so a general solution is necessary. I tried out uninstalling all extensions and remarked that the functions are called also from inside the core without having a $res. I didn't try to find the caller because I think that t3lib should tolerate empty parameters without unnecessary warnings.

A debug-Mode which runs without my "if ($res) { ... }" but with a debug_backtrace-function perhaps could be included too -- But for that case the Output sometimes will get to long, so the debug function has to be case-dependent.

endorsement:
A call of a function with an empty parameter ($res) calls an error but in most cases is no fault in sense of any function. So the conclusion of Ingo is missing that case which is responsable for most warnings.

Problem also occurs with 4.1.1 and 4.1.2 of typo3. I am seeing this warning message also on the frontend (and in the backend):

Warning: mysql_fetch_assoc(): supplied argument is not a valid MySQL result resource in
/srv/www/vhosts/domainname.de/httpdocs/typo3_src-4.1.2/t3lib/class.t3lib_db.php on line 796

After reloading the page the warning disappears.
PHP Version: 4.4.0
MySQL: 4.1.13

Line 796 in class.t3lib_db.php:
function sql_fetch_assoc($res) {
$this->debug_check_recordset($res);
return mysql_fetch_assoc($res); // Line 796
}

Had the same problem with one installation after upgrade - for me dropping cache_pages and recreating with

CREATE TABLE cache_pages (
id int(11) unsigned NOT NULL auto_increment,
hash varchar(32) NOT NULL default '',
page_id int(11) unsigned NOT NULL default '0',
reg1 int(11) unsigned NOT NULL default '0',
HTML mediumblob NOT NULL,
temp_content int(1) NOT NULL default '0',
tstamp int(11) unsigned NOT NULL default '0',
expires int(10) unsigned NOT NULL default '0',
cache_data mediumblob NOT NULL,
KEY page_id (page_id),
KEY sel (hash,page_id),
PRIMARY KEY (id)
) TYPE=InnoDB;

worked it out.

The method debug_check_recordset in class.t3lib_db.php could solve that problem, I think - if applied correctly.
This method returns false if $res is invalid and true if it is valid. It's called by nearly all sql_xxxxx methods, but the return value is not evaluated!

For example:
function sql_fetch_assoc($res) {
$this->debug_check_recordset($res);
return mysql_fetch_assoc($res);
}
could be rewritten as:
function sql_fetch_assoc($res) {
if ($this->debug_check_recordset($res))
return mysql_fetch_assoc($res);
}
(or such).

I'm seeing similar errors in our apache log files and was a bit surprised to find how debug_check_recordset is implemented. Would it be safe to do something like:

function sql_fetch_assoc($res) {
if ($this->debug_check_recordset($res)) {
return mysql_fetch_assoc($res);
}
else {return($this->sql_error()); }
}

And let the caller handle any errors from there?

I have the same problem:

Warning: mysql_fetch_assoc(): supplied argument is not a valid MySQL result resource in /htdocs/typo3/typo3_src-4.2.0/t3lib/class.t3lib_db.php on line 1047
Warning: mysql_fetch_assoc(): supplied argument is not a valid MySQL result resource in /htdocs/typo3/typo3_src-4.2.0/t3lib/class.t3lib_db.php on line 1047
Warning: mysql_fetch_assoc(): supplied argument is not a valid MySQL result resource in /htdocs/typo3/typo3_src-4.2.0/t3lib/class.t3lib_db.php on line 1047
Warning: Cannot modify header information - headers already sent by (output started at /htdocs/typo3/typo3_src-4.2.0/t3lib/class.t3lib_db.php:1047) in /htdocs/typo3/typo3_src-4.2.0/typo3/template.php on line 632

If I am in the Extension Manager and want to change settings of a Extension or if I want to install a Extension, it is very hard to do because I have to use the Tab-Key to navigate through it because I can't click anything because of the errors.
Perhaps it is a bug of an extension?

confirmation of the problem for T3 version 4.2.0 on: 4.0.24_Debian-10sarge3-log

no prob on: 5.0.32-Debian_7etch5-log

hth alex

Same Problem after upgrading from T3 4.0 to 4.2.1 on a machine running MySQL Version 4.0.

Command 'SHOW CHARACTER SET' is only supported from 4.1 upwards. Version Requirement for TYPO3 4.2 should be officially raised to mysql 4.1 so people are warned.

See the extension debug_mysql_db for a solution to this.

An additional patch is needed however.