[TYPO3-core] Fix for "debug_check_recordset" in t3lib_db

[Bernhard Kraft]

Martin Kutschker wrote:

> debug_check_recordset() tells the caller if there is a problem (it returns 
> FALSE), yet this is not even used.
> 
...
> This should, if we want to be save, more like that
> 
> function sql_fetch_row($res)    {
>    if ($this->check_mysql_result($res)) {
>      return mysql_fetch_row($res);
>    } else {
>      return FALSE;
>    }
> }

I also thought about this - but as Dmitry wrote in his mail this is probably not
what the user wants.

Currently when you fetch records from an invalid mysql-result yout get a PHP error
message at the top of your page - this sometimes helps the developer to know that
(and where) an error occurs.

Everybody currently is used that he gets those warnings if a result is not valid ...
so changing that and making a "silent log" would probably make it hard for some
developers to debug errors ...

I mean if you haven't cc_devlog installed the error/warning simply gets dropped.



But for now:
I know there is a debug-functin call after every call to mysql_query in
t3lib_db.

I just tested the site again where I had problems yesterday (sqlDebug wasn't turned on).
And now the invalid result resource get's logged to cc_devlog even with the:

if (!$res) {

statement ... (as dmitry mentioned that should be enough) ... I don't know what the
problem was yesterday - so it didn't get logged :( :(

probably because I had "Venkman" running (JS debugger) - as I had to debug an IRRE problem
(new records didn't get created) ... I assume venkman stopped at the breakpoint which kept
cc_devlog from being filled ... or something like that.


So no matter.

I take back the SVN request :)

To answer Dmitrys questions:
-------
Can it really happen that $res is not a resource or null or false?
mysql_fetch_xxx returns only those three I think. Or you want to extend
it generally, for custom extensions?
-------

No ... mysql_query will either return a valid resource of "false/null" ... so another reason
for not making the change.

I guess I wrote to the core list to quickly before investigating the problem more intensive.


So the only thing which would be left is to store the failed query into cc_devlog - but as Martin
wrote you can't be sure that "->debug_lastBuiltQuery" contains the query for which the currently checked
result is for ...

So I think it would make more sense to put a t3lib_div::devLog call into the "->debug()" method
of t3lib_db ...


In fact my problem yesterday was that I had to debug an AJAX call - so i didn't notice that there was
an SQL error in the XMLresponse ... It would have helped if those well known debug-messages when SQL
errors occur get logged to cc_devlog (the red boxes - when SQLdebug is set in the install tool)


attached a diff which makes this happen ...

after all I am just not happy with the way how AJAX scripts with SQL errors can get debugged.


greets,
Bernhard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch_t3lib_db_2007-09-06.diff
Type: text/x-patch
Size: 749 bytes
Desc: not available
Url : http://lists.netfielders.de/pipermail/typo3-team-core/attachments/20070906/a8c9c83a/attachment.bin