TYPO3 Core

I wasn't able to reproduce that on a similar setup. Could you try out the latest trunk? Can you always reproduce that or just in certain scenarios?

I got the same problem. But the statement seems correct.
Anyway I'll add two screenshots.

I was able to drop these tables using phpmyadmin, so it's not a problem of rights. This should also lead to another array, wouldn't it?

As the first error appears on top of the em window, maybe there are some leading characters before the first statement. Or there are some encoding problems?

Which PHP version, MySQL version, OS, Webserver is TYPO3 running?

TYPO3 4.5-dev (trunk)
PHP Version 5.3.3-7
Web Server Apache/2.2.16 (Debian)
mysql 5.1.49
OS linux

The screenshots looks like the errors here. The error message displays on top and also under the statement in the red box.

I am currenly using https://svn.typo3.org/TYPO3v4/Core/tags/TYPO3_4-5-0rc1 rev 10272 which is the same as current trunk except the version number.

The error is persistent and thus always reproducable.

I just tried to find out where the wrong SQL-Statement are generated, but i did not succeed. What i found out:

"print_r($remove_statements);" inserted after 5670 in /typo3/sysext/install/mod/class.tx_install.php

returns

Array
(
[drop_table] => Array
(
[828e14a3195343a600ac3c49f8276d8f] => DROP TABLE zzz_deleted_be_layouts;
[0f90c34c2da6913dacbeb2515eeaa67e] => DROP TABLE zzz_deleted_sys_refindex_rel;
[577ae89305d2f32d45f24f13abc415d1] => DROP TABLE zzz_deleted_sys_refindex_res;
[2118e9c545b95ce577f80f54f667fd78] => DROP TABLE zzz_deleted_sys_refindex_words;
[5bc6b005ae299bb7cfa16a179f1b6bf7] => DROP TABLE zzz_deleted_sys_workspace;
[460a6f57048e2e2b02e537f1a2cb5aaf] => DROP TABLE zzz_deleted_tx_mwimagemap_area;
[9fd97582469da935cb6c8d5060273735] => DROP TABLE zzz_deleted_tx_mwimagemap_bcolors;
[caeda163d80ab7743d4e5c03fa27d1a3] => DROP TABLE zzz_deleted_tx_mwimagemap_map;
[1bafa4cce2a774a0280c9cc425e5222a] => DROP TABLE zzz_deleted_tx_mwimagemap_point;
)

[tables_count] => Array
        (
            [828e14a3195343a600ac3c49f8276d8f] => 
            [0f90c34c2da6913dacbeb2515eeaa67e] => 
            [577ae89305d2f32d45f24f13abc415d1] => 
            [2118e9c545b95ce577f80f54f667fd78] => 
            [5bc6b005ae299bb7cfa16a179f1b6bf7] => 
            [460a6f57048e2e2b02e537f1a2cb5aaf] => Records in table: 1
            [9fd97582469da935cb6c8d5060273735] => 
            [caeda163d80ab7743d4e5c03fa27d1a3] => Records in table: 1
            [1bafa4cce2a774a0280c9cc425e5222a] => 
        )

)

"print($string);
" inserted after 1070 in /t3lib/class.t3lib_install.php

returns

DROP TABLE zzz_deleted_be_layouts;
DROP TABLE zzz_deleted_sys_refindex_rel;
DROP TABLE zzz_deleted_sys_refindex_res;
DROP TABLE zzz_deleted_sys_refindex_words;
DROP TABLE zzz_deleted_sys_workspace;
DROP TABLE zzz_deleted_tx_mwimagemap_area;
DROP TABLE zzz_deleted_tx_mwimagemap_bcolors;
DROP TABLE zzz_deleted_tx_mwimagemap_map;
DROP TABLE zzz_deleted_tx_mwimagemap_point;

This only happens with DBAL activated => reproduceable now. I'll try to contact Xavier to get this fixed ASAP. Thanks for your report and details!

Problem found, analyzed and locally patched but I want to understand where the error in DBAL code comes from

Please give feedback whether it solves your problem... I guess so :-)

Deleting tables in the install tool works with your patch like expected.

I am not sure if the patch works in every case, because of the three lines above the line you changed:

if ($this->lastParsedAndMappedQueryArray['type'] 'INSERT') {
return mysql_query($compiledQuery, $this->link);
}
return mysql_query($compiledQuery[0], $this->link);

It looks like there was a reason for checking $this->lastParsedAndMappedQueryArray['type'] 'INSERT' to decide what to return. Is this obsolete now?

For me, yes, it's obsolete, I probably will remove them. I went back to see when this [0] was introduced as there is cases (with updates) where multiple statements are returned but 1) this is like that since the very beginning (since code has been moved from CVS to SVN) by the former maintainer and 2) $compiledQuery can only be a string.

As such, this is a bug from the very beginning but I guess nobody ever tried to really use TYPO3 with a MySQL database, this is why it was not spotted until now.

The test with INSERT is to be similar to code used when native driver is not used. As said it does not make sense to keep this and I will start by commenting it out and remove it at some point in the future.

Committed to:

- DBAL trunk (rev. 42595)
- DBAL_1-2 (rev. 42596)
- DBAL_1-1 (rev. 42597)
- DBAL_1-0 (rev. 42598)