Druckbare Version
Hallo zusammen,
ich habe gerade ein contao 3.5.40 (fast) auf 4.13.35 aktualisiert ...
Im contao-manager bleibt noch eine Datenbankaktualisierung übrig
Das lässt sich nicht ausführen mit der MeldungCode:CREATE UNIQUE INDEX uuid ON tl_files (uuid)
ProdCache habe ich schon gelöscht.Code:Die Änderungen konnten nicht angewendet werden. Möglicherweise wurde die Datenbank geändert, bitte prüfe nochmals und versuche es erneut.
Hat noch jemand eine Idee, wie ich da weiterkomme?
Viele Grüße,
conter
Möglicherweise wurde die Datenbank geändert:Zitat:
Zitat von conter
Stimmen die Zugungsdaten zu deiner Datenbank in deiner .env / env.local / parameters.yaml?
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:
nach ausführen des installtools gibt es Fehler 500 und in var/logs steht folgender FehlerCode:Datenbank aktualisieren
Hier können Sie das Datenbank-Schema aktualisieren.
Spalten anlegen
Alle auswählen
CREATE UNIQUE INDEX uuid ON tl_files (uuid)
Code:[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
Irgendwo hat sich eine doppelte uuid eingeschlichen, wenn ich das richtig sehe. Das wirst Du suchen und beseitigen müssen.
Hallo zusammen,
es sind tatsächlich sehr viel doppelte und mehrfache uuids vorhanden ...
hier nur ein kurzer Auszug
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.Code:
uuid COUNT(*)
0x02efbfbd11efbfbd56efbfbd11efbfbd 3
0x02efbfbd5fefbfbdc68c11efbfbd641c 2
0x0747efbfbdefbfbd0f11efbfbd641c6f 2
0x0befbfbd18efbfbd27efbfbd11efbfbd 6
0x0befbfbd59efbfbd27efbfbd11efbfbd 5
0x0befbfbd68efbfbd27efbfbd11efbfbd 3
0x0befbfbd69efbfbd27efbfbd11efbfbd 2
Dies habe ich eben eingestellt
Anhang 26860
(Die DB auf dem neuen war vorher komplett gelöscht/leer.)
Wieder mit der gleichen uuid Meldung :(
Viele Grüße,
conter
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
Beim Unique Index darf es auch nur 1 Mal NULL geben. Also beim Bereinigen auch darauf achten.
Hattest du die Contao 3 Datenbank direkt weiter verwendet oder die Datenbank vorher exportiert und wieder importiert? (für eine Kopie)
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.
Anhang 26861
wirft Fehler
Beim checken der 3.5er DB überCode: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}
ergibt keine TrefferCode:SELECT * FROM `tl_files` WHERE uuid IS NULL;
Dafür habe ich bei pid
4 Einträge mit NULLCode:SELECT * FROM `tl_files` WHERE pid IS NULL;
Das ist noch unbeantwortet: https://community.contao.org/de/show...l=1#post579054
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
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.
In diesem Screenshot sieht man jedenfalls nicht, ob binäre Daten in Hex Notation exportiert wurden. Das muss sichergestellt sein.Zitat:
Zitat von conter
Hmmm,
adminer scheint das nicht herzugeben:
https://sourceforge.net/p/adminer/bu...-features/741/Zitat:
#741 There is no --hex-blob option, so dumps are not valid text files
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
In phpMyAdmin kann man das im Export angeben.
Wenn auf die Datenbank von extern zugegriffen werden kann, kannst Du für Windows HeidiSQL verwenden.
Ich habe leider nur die Datenbank-Verbindungsdaten aus localconfig.php
und kann mich deshalb nicht von meinem eigenen phpmyadmin oder mysqlworkbench verbinden, weil mir der dbHost fehlt.Code:$GLOBALS['TL_CONFIG']['dbDriver'] = 'MySQLi';
$GLOBALS['TL_CONFIG']['dbHost'] = 'mysql';
$GLOBALS['TL_CONFIG']['dbUser'] = '####';
$GLOBALS['TL_CONFIG']['dbPass'] = '####';
$GLOBALS['TL_CONFIG']['dbDatabase'] = '####';
Wenn adminer versagt ist meine nächste Hoffnung einen anderen one-file-databasemanager zu finden, den ich wie adminer auf den Kundenserver hochladen kann ...
Ich würde in dem Fall den Hoster nach einer DB-Backup fragen.Zitat:
Zitat von conter
Danach so schnell wie möglich umziehen.
Wer ist der Hoster?
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
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.
Mal schauen, wie es weiter geht.
Danke jedenfalls schon mal für eure Unterstützung bis hier hin!
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.
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.
Und hier die "neueste Version" der Contao3-Erweiterung:
Anhang 26868
Hallo do_while,
cool, vielen Dank! Probiere ich morgen gleich aus.
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
mit dem gleichen Fehler wie oben :(Code:ALTER TABLE `tl_files` ADD UNIQUE KEY `uuid` (`uuid`);
Viele Grüße,
conter
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.
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.
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.
Wissen wir denn, dass diese Extension das richtig macht?Zitat:
Zitat von 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.
Das kann auch nur Zufall sein ;). Postet mal einen Auszug des Dumps von tl_files wie er von der Extension erzeugt wird (als Datei).
Ja, in der bereitgestellten ZIP-Version (siehe oben), werden alle Binary-Felder als 0xXXXXX... exportiert.Zitat:
Zitat von Spooky
Das trifft auch bei BLOB-Feldern zu.
Vielleicht hilft es ja: Bei Domainfactory 64 SharedHosting ruft man phpmyadmin über /sqladmin direkt hinter der betreffenden Domain auf. Login dann mit den Datenbankdaten.Zitat:
Zitat von conter
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
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 ...
Anhang 26872
Das war hilfreich, danke!Zitat:
Zitat von swinde
Ich konnte mich über /sqladmin in phpmyadmin anmelden mit den Daten aus system/config/localconfig.php
Seltsamerweise ist dort keine Datenbank angelegt :eek: "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, entwederZitat:
Zitat von conter
mysql = MySQL5.7
localhost= mariaDB
Die meisten haben MySQL5.7 benutzt.
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:
Anhang 26891
Anhang 26892
Anhang 26893
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