TYPO3 Core

What is the actual SQL error message?

exec_INSERTquery

caller: TYPO3\CMS\Core\Database\DatabaseConnection::exec_INSERTquery
ERROR: Column 'ref_uid' cannot be null

Thanks.

You reported this for 6.2, but I guess you ran the ref index update on 4.7. So the bug is on 4.7 then, right?

That's what I assumed too, but according to the discussion in the German list, the update has been done on 6.2.3 after the migration tool gave the advice to run a reference index update before.

Well I guess we have to rephrase this text.
You should update the reference index BEFORE upgrading in the old version.

It doesn't make a difference though, since this is still a bug in the reference index updater, which should not insert NULL values but the correct defaults.

BTW: Here is the discussion http://forum.typo3.org/index.php/t/204087/

It seems that the reference index had been updated with 4.7.x and everything was reported to be OK.
Then the upgrade was done using "Migrate all file links of RTE-enabled fields to FAL" which produced the report "There are currently 52 links to update. Update failed!"
There was a hint to do a reference index upgrade, which is why the update has been run on 6.2.3 again, which produced the SQL errors mentioned above.

IMHO the problem is, that there is neither a reference table nor a reference uid, when the reference points to a non FAL based group field of the internal type "file".

I guess there are three issues actually.

• First one is that internal_type 'file' seems to be not handled correctly.
• Second one is that there's a missing check somewhere that the ref_table is not valid
• Third one is that the upgrade wizard obviously does not work in all cases, since it should be able to convert all links in the first run.

So we need a DB dump or somebody debugging the upgrade wizard on this instance to figure out why it says the update fails. "What's wrong with these links".

Both is possible. It is a test instance, and so you can got an admin login by email.
Unless you'd prefer a DB Dump?

Hi!
Well admin sounds good already, but how many content elements are in this instance?
If it is over 100, I'd prefer if you could do a real debugging session.

tt_content has ca. 1800 records.

Sorry I do not understand what you mean:
"if you could do a real debugging session" ?

debuggin with your IDE via xdebug to find out which records are affected by this problem.

I'm not a developer, and so I have no IDE installed.

Ok, do you know if your server has xdebug enabled for remote debugging?

No, xdebug.so is not pre-installed, but it is possible to do this. Provider ist jweiland.net and from support I#ve got this answer:

Ja, die Nutzung von xdebug ist möglich. In den php Einstellung in der Domainkonfiguration muss die domainspezifische Einstellung aktiviert werden. Dann muss unter Zend-Extensions der Pfad zu einer lokalen xdebug.so eintragen werden.

Unter den sonstigen Einstellungen müsste dann noch ein Eintrag

xdebug.remote_enable = on

vorgenommen werden. Alternativ können die Einstellungen auch in lokale php.ini

Dateien gepackt werden, die dann in das jeweilige PHP Quellcode Verzeichnis kopiert werden.

Eine Anleitung zur generellen Aktivierung von weiteren PHP-Erweiterungen finden Sie unter dem nachfolgenden Link:

http://jweiland.net/typo3-hosting/anleitung/php/weitere-php-module.html

What is the status? Did you wait for something?

Sorry, I it's currently not possible for me to invest more time into getting debugging running on your hosting provider.
If you want, you can send me a complete DB dump and filesystem dump of the 4.7.17 instance, so I can try an upgrade locally on my dev-server, where I've all necessary tools at hand.

• Are the files reported missing really missing or are they present?
• Are those files really used in the the 4.7 installation? (Please check the DB with the uids specified in the error messages)

We need to find out, if the data is inconsistent on 4.7 or if the update wizards do something wrong.

I just pointed out, what the actual problem is, but maybe this has been overlooked somehow ;-)

IMHO the problem is, that there is neither a reference table nor a reference uid, when the reference points to a non FAL based group field of the internal type "file".

This results in insert queries with NULL values, which are throwing errors with fields set to NOT NULL.

Is this still an issue?

Seems this has been fixed together with #64253. In line 198 of typo3/sysext/core/Classes/Database/ReferenceIndex.php there is now a check that should prevent the NULL values from being inserted.

foreach ($relations as $k => $datRec) {
    if (!is_array($relations[$k])) {
        continue;
    }
...