Update von 3.5 auf 4.13 / CREATE UNIQUE INDEX uuid ON tl_files (uuid) bleibt übrig

[conter]

Hallo zusammen,

ich habe gerade ein contao 3.5.40 (fast) auf 4.13.35 aktualisiert ...
Im contao-manager bleibt noch eine Datenbankaktualisierung übrig

CREATE UNIQUE INDEX uuid ON tl_files (uuid)

Das lässt sich nicht ausführen mit der Meldung

Die Änderungen konnten nicht angewendet werden. Möglicherweise wurde die Datenbank geändert, bitte prüfe nochmals und versuche es erneut.

ProdCache habe ich schon gelöscht.

Hat noch jemand eine Idee, wie ich da weiterkomme?

Viele Grüße,
conter

[zoglo]

Hallo zusammen,

Die Änderungen konnten nicht angewendet werden. Möglicherweise wurde die Datenbank geändert, bitte prüfe nochmals und versuche es erneut.

Möglicherweise wurde die Datenbank geändert:

Stimmen die Zugungsdaten zu deiner Datenbank in deiner .env / env.local / parameters.yaml?

[conter]

Hallo zoglo,

danke für deine Antwort.
Ich denke schon, dass die Zugangsdaten in parameters.yml stimmen, ich habe von 3.5 zu 4.13 updaten können.
Das Backend kann ich aufrufen, da sieht es soweit gut aus, die Seiten sind wie es scheint alle da, ebenso die Dateien in files.

Das installtool kann ich aufrufen. es bietet mir (genau wie der Manager) noch eine Änderung an:

Datenbank aktualisieren
Hier können Sie das Datenbank-Schema aktualisieren.
Spalten anlegen
Alle auswählen
CREATE UNIQUE INDEX uuid ON tl_files (uuid)

nach ausführen des installtools gibt es Fehler 500 und in var/logs steht folgender Fehler

[2023-12-30T16:46:20.462181+00:00] request.CRITICAL: Uncaught PHP Exception Doctrine\DBAL\Exception\UniqueConstraintViolationException: "An exception occurred while executing a query: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '\xEF\xBF\xBD\xEF\xBF\xBDh\xEF\xBF\xBDSK\x11\xE3\xA4\xA8' for key 'uuid'" at /var/www/clients/client2/web626/web/v1/vendor/doctrine/dbal/src/Driver/API/MySQL/ExceptionConverter.php line 62 {"exception":"[object] (Doctrine\\DBAL\\Exception\\UniqueConstraintViolationException(code: 1062): An exception occurred while executing a query: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '\\xEF\\xBF\\xBD\\xEF\\xBF\\xBDh\\xEF\\xBF\\xBDSK\\x11\\xE3\\xA4\\xA8' for key 'uuid' at /var/www/clients/client2/web626/web/v1/vendor/doctrine/dbal/src/Driver/API/MySQL/ExceptionConverter.php:62)\n[previous exception] [object] (Doctrine\\DBAL\\Driver\\PDO\\Exception(code: 1062): SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '\\xEF\\xBF\\xBD\\xEF\\xBF\\xBDh\\xEF\\xBF\\xBDSK\\x11\\xE3\\xA4\\xA8' for key 'uuid' at /var/www/clients/client2/web626/web/v1/vendor/doctrine/dbal/src/Driver/PDO/Exception.php:28)\n[previous exception] [object] (PDOException(code: 23000): SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '\\xEF\\xBF\\xBD\\xEF\\xBF\\xBDh\\xEF\\xBF\\xBDSK\\x11\\xE3\\xA4\\xA8' for key 'uuid' at /var/www/clients/client2/web626/web/v1/vendor/doctrine/dbal/src/Driver/PDO/Connection.php:33)"} []

Viele Grüße,
conter

[mlweb]

Irgendwo hat sich eine doppelte uuid eingeschlichen, wenn ich das richtig sehe. Das wirst Du suchen und beseitigen müssen.

[conter]

Hallo zusammen,

es sind tatsächlich sehr viel doppelte und mehrfache uuids vorhanden ...

hier nur ein kurzer Auszug

uuid 	                                        COUNT(*) 	
0x02efbfbd11efbfbd56efbfbd11efbfbd 	3
0x02efbfbd5fefbfbdc68c11efbfbd641c  2
0x0747efbfbdefbfbd0f11efbfbd641c6f 	2
0x0befbfbd18efbfbd27efbfbd11efbfbd 	6
0x0befbfbd59efbfbd27efbfbd11efbfbd 	5
0x0befbfbd68efbfbd27efbfbd11efbfbd 	3
0x0befbfbd69efbfbd27efbfbd11efbfbd 	2

Ich musste den Dump aus dem 3.5er contao per adminer ziehen, vielleicht ist dabei was schief gelaufen, bin nicht so fit mit dem tool.

Dies habe ich eben eingestellt
adminer.png

(Die DB auf dem neuen war vorher komplett gelöscht/leer.)

Wieder mit der gleichen uuid Meldung

Viele Grüße,
conter

[lucina]

Gleiche UUIDs sind ja ungefähr so häufig wie die Wahrscheinlichkeit, mehrfach im Lotto zu gewinnen und dabei jedesmal vom Blitz getroffen zu werden.

Sind die bereits in der Ausgangsdatenbank doppelt?


Gesendet von iPhone mit Tapatalk

[cliffparnitzky]

Beim Unique Index darf es auch nur 1 Mal NULL geben. Also beim Bereinigen auch darauf achten.

[Spooky]

Hattest du die Contao 3 Datenbank direkt weiter verwendet oder die Datenbank vorher exportiert und wieder importiert? (für eine Kopie)

[conter]

Moin und frohes Neues Jahr euch allen!

Ich bin jetzt noch mal einen Schritt zurück gegangen.
Das zu aktualisierende contao war schon 3.5.40, deshalb hatte ich dessen dump zunächst direkt zum aktualisieren benutzt.

Jetzt habe ich eine Testumgebung mit einem leeren contao 3.5.40 angelegt und dort dump und Dateien eingespielt.
Dort bekomme ich leider das gleiche Problem beim installtool.

installfehleruuid.png
wirft Fehler

Fatal error: Uncaught exception Exception with message Query error: Duplicate entry '?aQ\xE2\xA5^\x11\xEE\xBFn\x02B\xAC\x1B\x00\x03' for key 'uuid' (ALTER TABLE `tl_files` ADD UNIQUE KEY `uuid` (`uuid`);) thrown in system/modules/core/library/Contao/Database/Statement.php on line 295

#0 system/modules/core/library/Contao/Database.php(207): Contao\Database\Statement->query('ALTER TABLE `tl...')
#1 system/modules/core/controllers/BackendInstall.php(608): Contao\Database->query('ALTER TABLE `tl...')
#2 system/modules/core/controllers/BackendInstall.php(181): Contao\BackendInstall->adjustDatabaseTables()
#3 contao/install.php(20): Contao\BackendInstall->run()
#4 {main}

Beim checken der 3.5er DB über

SELECT * FROM `tl_files` WHERE uuid IS NULL;

ergibt keine Treffer

Dafür habe ich bei pid

SELECT * FROM `tl_files` WHERE pid IS NULL;

4 Einträge mit NULL

[Spooky]

Das ist noch unbeantwortet: https://community.contao.org/de/show...l=1#post579054

[conter]

Hallo Spooky,

ich habe auf einem externen Server per adminer einen dump aus einem contao 3.5.40 gezogen.

Dann habe ich auf unserem Server zwei Testumgebungen angelegt:

Eine, wo ich ein frisches contao 3.5.40 installiert und dann dump und files importiert habe und direkt weiter auf 4.13 aktulisiert habe (#1).

Und eine wo ich ein frisches contao 3.5.40 installiert und dann dump und files importiert habe und es auf 3.5.40 gelassen habe und das Installtool hab laufen lassen (#9)

Kann es an einem falschen adminer-Export liegen? Ich hatte oben die gewählte Einstellung als Bild gepostet (#5).

Viele Grüße,
conter

[do_while]

Ich würde denken, dass die binären Zeichen im Dump das Problem beim Rückschreiben auslösen.

Ich würde beim mysqldump die Option --hex-blob mit angeben, dann werden binäre Daten in Hex-Schreibweise in den Dump geschrieben.

[Spooky]

Kann es an einem falschen adminer-Export liegen? Ich hatte oben die gewählte Einstellung als Bild gepostet (#5).

In diesem Screenshot sieht man jedenfalls nicht, ob binäre Daten in Hex Notation exportiert wurden. Das muss sichergestellt sein.

[conter]

Hmmm,

adminer scheint das nicht herzugeben:

#741 There is no --hex-blob option, so dumps are not valid text files

https://sourceforge.net/p/adminer/bu...-features/741/

Ich habe das neueste Adminerpaket runtergeladen, das ist, wie ich eben gesehen habe, aber leider auch schon von 2021

Ich brauche so eine ähnliche Version, die ich auf den Server hochladen und Ausführen kann.
Der gegenwärtige Hoster gibt mir nichts, das ich bei Server eintragen könnte, sonst hätte ich es längst per workbench oder phpmyadmin machen können.
Leider auch keinen SSH-Zugang.

Kennt jemand ein neueres Programm das ähnlich adminer funktioniert?

Viele Grüße,
conter

[do_while]

In phpMyAdmin kann man das im Export angeben.

Wenn auf die Datenbank von extern zugegriffen werden kann, kannst Du für Windows HeidiSQL verwenden.

[conter]

Ich habe leider nur die Datenbank-Verbindungsdaten aus localconfig.php

$GLOBALS['TL_CONFIG']['dbDriver'] = 'MySQLi';
$GLOBALS['TL_CONFIG']['dbHost'] = 'mysql';
$GLOBALS['TL_CONFIG']['dbUser'] = '####';
$GLOBALS['TL_CONFIG']['dbPass'] = '####';
$GLOBALS['TL_CONFIG']['dbDatabase'] = '####';

und kann mich deshalb nicht von meinem eigenen phpmyadmin oder mysqlworkbench verbinden, weil mir der dbHost fehlt.

Wenn adminer versagt ist meine nächste Hoffnung einen anderen one-file-databasemanager zu finden, den ich wie adminer auf den Kundenserver hochladen kann ...

[mlweb]

Der gegenwärtige Hoster gibt mir nichts, das ich bei Server eintragen könnte, sonst hätte ich es längst per workbench oder phpmyadmin machen können.
Leider auch keinen SSH-Zugang.

Ich würde in dem Fall den Hoster nach einer DB-Backup fragen.

Danach so schnell wie möglich umziehen.

Wer ist der Hoster?

[conter]

Hallo Maren,

der Hoster ist DomainFactory, sollte also eigentlich kein Problem sein.
Das Problem ist wahrscheinlich der Ersteller der Website, der sich jetzt schwer tut, das ganze zu übergeben
Ich habe beim Kunden noch mal angefragt, ob Sie den Zugang zum Kundenlogin bei DF anfordern können bzw. den Ersteller bitten, den Dump über den DF-phpmyadmin zu erstellen.

Viele Grüße,
conter

[mlweb]

DF stellt auf jeden Fall phpMyAdmin zur Verfügung.
Ich liebe Dienstleister, die sich bei einer Übergabe nicht kooperativ verhalten. In meinen Augen vollkommen unproffessionell.

[conter]

Mal schauen, wie es weiter geht.

Danke jedenfalls schon mal für eure Unterstützung bis hier hin!

[tab]

Blöde Idee:Könnte man nicht die passende Version von BackupDB manuell installieren (im Original)? Das sollte doch eigentlich laufen, ohne dass dabei zuerst die Datenbank geändert wird.
Andererseits wäre dann der Tipp wahrscheinlich von @do_while schon gekommen. Vorsicht ist also in jedem Fall anbracht, es gibt nur das eine korrekte Original der DB, die Dumps sind sehr wahrscheinlich Schrott.

Wobei, sollten die nicht zumindest mit der selben Version von Adminer wieder in eine neue Datenbank eingespielt werden können? Ich kann mich leider nur noch sehr dunkel an die Zeit erinnern, als ich zuletzt dieses Problem hatte. Adminer habe ich damals nicht benutzt, aber bei den Dumps mit phpMyAdmin war es jedenfalls so, dass manche Versionen von phpMyAdmin den erzeugten Dump korrekt eingelesen haben und andere eben nicht.

[do_while]

Da hat @tab natürlich recht, in Contao 3 war ja alles noch in system/modules, da könnte man das BackupDB einfach reinkopieren. Cache löschen war da auch noch nicht, das müßte also auch gleich laufen. Ich muss mal nach der letzten Contao 3-Version von BackupDB gucken, die war ja noch nicht auf Github und das Repository ist inzwischen abgeschaltet.

Ich suche heute Abend und stelle es dann hier noch als ZIP zur Verfügung.

[do_while]

Und hier die "neueste Version" der Contao3-Erweiterung:

BackupDB_Contao3.zip

[conter]

Hallo do_while,

cool, vielen Dank! Probiere ich morgen gleich aus.

[conter]

Hallo zusammen,

das Installieren von backupDB und das Exportieren der Datenbank darüber hat geklappt.

Leider kommt nach dem Import die gleiche Aufforderung beim installtool

ALTER TABLE `tl_files` ADD UNIQUE KEY `uuid` (`uuid`);

mit dem gleichen Fehler wie oben

Viele Grüße,
conter

[tab]

Das heißt dann wohl, dass die UUID-Duplikate schon in der Orignaldatenbank vorhanden waren. Hat die Seite denn noch einwandfrei funktioniert, wurden also überall noch die richtigen Bilder angezeigt? Einen Fehler wirft sowas in einer Contao 3.5.x Installation nicht unbedingt, da hier wohl der UNIQUE Key noch nicht angelegt wurde. Jetzt würde ich schauen, ob denn die Datensätze mit den selben UUIDs auch auf das selbe Bild (path) verweisen und falls nicht, welches der Bilder beutzt wird und eventuell, ob es sich nicht um Duplikate des selben Bilds mit unterschiedlichem Namen/Verzeichnis handelt. Wenn dann nur eins davon verwendet wird, kann man die anderen Datensätze löschen.

Bei einer großen Anzahl solcher Fehler kann das allerdings ziemlich aufwändig werden, so dass man das besser per Skript oder mit Datenbankabfragen zumindest teilweise automatisieren sollte.

[Spooky]

Den unique Index gibt es auch schon in Contao 3.

@conter wie genau hast du nun die Datenbank kopiert? Du musst --hex-blob bei mysqldump nutzen.

[tab]

Da es auch bei einem SQL-Dump via BackupDB passiert sind die Duplikate m.E. schon drin in der Contao 3 Datenbank. Mit Dumps von BackupDB hatte ich nie solche Probleme.
Zeigt Contao 3 nicht auch schon die UUID an in der Info vom Dateimanager? Falls ja, würde ich mir halt mal zwei Dateien rauspicken, die die selbe UUID haben im Dump und dann im Backend schauen, ob die UUIDs dieser Dateien auch da identisch angezeigt werden. Falls ja, dann ist der Fehler eh schon in der Datenbank drin.

[Spooky]

Da es auch bei einem SQL-Dump via BackupDB passiert sind die Duplikate m.E. schon drin in der Contao 3 Datenbank.

Wissen wir denn, dass diese Extension das richtig macht?

[tab]

Wie gesagt, damit hatte ich nie ein Problem in vielen Jahren Nutzung für SQL-Dumps, auch bei Umzügen. Auch alle meine Updates nach Contao 4 sind alle mit den Dumps von BackupDB passiert und ich hatte nie ein Duplikat.

[Spooky]

Das kann auch nur Zufall sein . Postet mal einen Auszug des Dumps von tl_files wie er von der Extension erzeugt wird (als Datei).

[do_while]

Wissen wir denn, dass diese Extension das richtig macht?

Ja, in der bereitgestellten ZIP-Version (siehe oben), werden alle Binary-Felder als 0xXXXXX... exportiert.
Das trifft auch bei BLOB-Feldern zu.

[swinde]

Ich habe leider nur die Datenbank-Verbindungsdaten aus localconfig.php

$GLOBALS['TL_CONFIG']['dbDriver'] = 'MySQLi';
$GLOBALS['TL_CONFIG']['dbHost'] = 'mysql';
$GLOBALS['TL_CONFIG']['dbUser'] = '####';
$GLOBALS['TL_CONFIG']['dbPass'] = '####';
$GLOBALS['TL_CONFIG']['dbDatabase'] = '####';

und kann mich deshalb nicht von meinem eigenen phpmyadmin oder mysqlworkbench verbinden, weil mir der dbHost fehlt.

Wenn adminer versagt ist meine nächste Hoffnung einen anderen one-file-databasemanager zu finden, den ich wie adminer auf den Kundenserver hochladen kann ...

Vielleicht hilft es ja: Bei Domainfactory 64 SharedHosting ruft man phpmyadmin über /sqladmin direkt hinter der betreffenden Domain auf. Login dann mit den Datenbankdaten.
Bei älteren Servern war es glaube ich mysql5.domain.tld‘ oder der IP-Adresse ‘127.0.0.3‘
https://www.df.eu/de/support/df-faq/...ccordion-22914

[tab]

Kann ich nur bestätigen. (Edit: Den Beitrag von @do_while) Mit einem Dump von Contao 3.5.x kann ich auf Anhieb nicht mehr dienen, aber sollte ja für @conter kein Problem sein.
Von einer 4.13 mal auszugsweise ein Teil der tl_files Tabelle ...

dump-auszug.txt

[conter]

Vielleicht hilft es ja: Bei Domainfactory 64 SharedHosting ruft man phpmyadmin über /sqladmin direkt hinter der betreffenden Domain auf. Login dann mit den Datenbankdaten.
Bei älteren Servern war es glaube ich mysql5.domain.tld‘ oder der IP-Adresse ‘127.0.0.3‘
https://www.df.eu/de/support/df-faq/...ccordion-22914

Das war hilfreich, danke!
Ich konnte mich über /sqladmin in phpmyadmin anmelden mit den Daten aus system/config/localconfig.php

Seltsamerweise ist dort keine Datenbank angelegt "Keine Datenbanken" wird angezeigt.

Der Kunde ist aber bald wieder aus dem Urlaub zurück ... stay tuned

[swinde]

Das war hilfreich, danke!
Ich konnte mich über /sqladmin in phpmyadmin anmelden mit den Daten aus system/config/localconfig.php

Seltsamerweise ist dort keine Datenbank angelegt "Keine Datenbanken" wird angezeigt.

Der Kunde ist aber bald wieder aus dem Urlaub zurück ... stay tuned

böse Falle bei DF! Du musst auswählen, entweder
mysql = MySQL5.7
localhost= mariaDB

Die meisten haben MySQL5.7 benutzt.

[conter]

Danke! Da war sie versteckt.
Mit meinen Einstellungen, die ich in phpmyadmin-Export immer nutze, hat es auch den uuid Fehler gegeben.

Ich lade mal die DB Einstellung, Tabellenansicht und Exporteinstellungen mal hoch.
Meine Einsteillungen:
db-kollation.png
tables.png
MySQL-5-7-phpMyAdmin-5-2-1.pdf

Wenn euch darin keine Fehler auffallen oder sowieso bitte ich euch noch um Tipps, wie ich die Datenbank bereinigen könnte bzgl. dieser uuids.

Viele Grüße,
conter