TYPO3 Core

BTW: if I check all the fields and "execute" the update, nothing happens, the list of database changes to be performed remains the same

Hi thank you for your reply. I will gladly be of help...how can I be of help? How can I check if I am on STRICT mode? (I'm using a MAMP enviroment just now).

If it is of help, after starting Mysql, this is the error log:

150111 15:09:16 mysqld_safe Starting mysqld daemon with databases from /Library/Application Support/appsolute/MAMP PRO/db/mysql
150111 15:09:17 [Warning] Using unique option prefix key_buffer instead of key_buffer_size is deprecated and will be removed in a future release. Please use the full name instead.
150111 15:09:17 [Warning] Setting lower_case_table_names=2 because file system for /Library/Application Support/appsolute/MAMP PRO/db/mysql/ is case insensitive
150111 15:09:17 [Note] Plugin 'FEDERATED' is disabled.
150111 15:09:17 InnoDB: The InnoDB memory heap is disabled
150111 15:09:17 InnoDB: Mutexes and rw_locks use GCC atomic builtins
150111 15:09:17 InnoDB: Compressed tables use zlib 1.2.3
150111 15:09:17 InnoDB: Initializing buffer pool, size = 128.0M
150111 15:09:17 InnoDB: Completed initialization of buffer pool
150111 15:09:17 InnoDB: highest supported file format is Barracuda.
150111 15:09:21  InnoDB: Waiting for the background threads to start
150111 15:09:22 InnoDB: 5.5.33 started; log sequence number 1467896902

Executing the query does not trigger anything in the log.

Does the same error occur in 6.2.x installs too?
And maybe 4.5?

If you could check that, that'd be awesome.

I am sure it does not occur in 6.2.x; cannot check in 4.5 sorry

Please try the following:

• open typo3/sysext/core/ext_tables.sql
• go to line 383 (or search for "combined_1")
• add spaces after the commas in the brackets

Check again in the install tool.

Before:

KEY combined_1 (original,task_type,configurationsha1),

After:

KEY combined_1 (original, task_type, configurationsha1),

I run the install tool > compare db but no... nothing happens: performing the update nothing changes; the only difference is the line:

ALTER TABLE sys_file_processedfile ADD KEY combined_1 (original, task_type, configurationsha1);

I've done another test on a Windows enviroment WAMP (PHP 5.5.12, Mysql 5.6.17) and here the error does not occur. After performing the changes in ext_tables.sql

ALTER TABLE sys_file_processedfile DROP KEY combined_1;
ALTER TABLE sys_file_processedfile ADD KEY combined_1 (original, task_type, configurationsha1);

Ok, I think the problem might be here somehow:

typo3/sysext/install/Classes/Service/SqlSchemaMigrationService.php

Function: getFieldDefinitions_database()

Can you debug $total['sys_file_processedfile']['keys'] here?

I still think that your MAMP returns something different than what TYPO3 expects ;-)

@Mathias Schreiber

I'd want to thank you very much for your time; can you guide me about how to do the debug? Alas, I'm not a programmer ;) something like "for dummies" ;)?

no problem.

we'll just to the "rambo" way of doing things.
At the end of the function it says "return $total;".

add two lines on top of that:

var_dump($total['sys_file_processedfile']['keys'] );
die();

The die() will exit the script immediately, so make sure to comment out this two lines later :)

ok, I like the "Rambo" way ;)

Added the lines after "//RDC"

public function getFieldDefinitions_database() {

[.....]
        // Compile key information:
        if (count($tempKeys)) {
            foreach ($tempKeys as $table => $keyInf) {
                foreach ($keyInf as $kName => $index) {
                    ksort($index);
                    $total[$table]['keys'][$kName] = $tempKeysPrefix[$table][$kName] . ' (' . implode(',', $index) . ')';
                }
            }
        }

        //RDC
        var_dump($total['sys_file_processedfile']['keys'] );
        die();

        return $total;

This is the result:

array(3) { ["PRIMARY"]=> string(17) "PRIMARY KEY (uid)" ["combined_1"]=> string(58) "KEY combined_1 (original,task_type(191),configurationsha1)" ["identifier"]=> string(40) "KEY identifier (storage,identifier(191))" }

ok, cool.
Do you see the difference?
Compare

YOURS: KEY combined_1 (original,task_type(191),configurationsha1)
TYPO3: KEY combined_1 (original,task_type,configurationsha1)

Please try this in MySQL (phpMyAdmin or alike):

SHOW KEYS FROM sys_file_processedfile;

The column called "Sub_part" on your system returns a value where it should not.
Same goes in the last key... see that your windows install says 199, while your MAMP says 191.

I think this is mamp related and there is no way TYPO3 can deal with it :(

so the correct value is "NULL"?
Apart from that, I don't like what happened because it is very difficult to trace such an error; I mean, even if I want to change it manually, it is not a good news if the enviroment makes the database not consistent (I hope I made myself clear)

The only thing I can test is the following: I don't remember if I created the empty DB via phpmyadmin and then choose it in the installation procedure or I had it created by TYPO3 itself during the installation.

If you think this could aid, I'll do this test removing the whole installation and creating everything again

Personally, I'd ignore the error on your local machine.
As you see this is what TYPO3 instructs your DB to do:

ALTER TABLE sys_file_processedfile ADD KEY combined_1 (original,task_type,configurationsha1);

The result is somewhat different from that instruction and TYPO3 can only check "did the DB do what I told it to do?"

One last thing you can try is to manually delete the key in PHPMyAdmin and then run the SQL statement above.
Maybe it shows an error or a warning.

I run into same issue in production environment and solved it, by using "utf8_general_ci" instead of "utf8mb_general_ci" as collation, which was pre configured.

This makes the different for the "Sub_part" value beeing set to 199 what was expected by TYPO3 instead of 191, which was set, when creating tables with collation "utf8mb_general_ci".