DB-Fehler bei Migration 3.10.x zu 4.x

    Guten Abend und vielen Dank für die Tipps.

    Ich bin gerade wieder zu meiner Sicherung 3.10.6 zurückgekehrt


    In der DB habe ich die unter #17 genannten Tabellen gelöscht (#_finder_logging, #_mail_template, #_workflows...... 4 Stück, #_history, wenn vorhanden" gab es bei mir nicht)

    Unter => Global Configuration / Server steht bei mir Database tables => prefix => jsd_

    Diese Tabellen habe ich aber nicht angerührt.


    DB Version: 5.5.5-10.1.48-MariaDB-0+deb9u2


    Ergebnis DB reparieren (da gab es nichts zu tun):

    • Database schema version (in #__schemas): 3.10.0-2021-05-28.
    • Update version (in #__extensions): 3.10.6.
    • Database driver: mysqli.
    • 190 database changes were checked.
    • 219 database changes did not alter table structure and were skipped.

    Letzter Versuch der Migration war leider auch erfolglos. Nachdem ich mich jetzt wirklich über viele Stunden mit dem Thema beschäftigt habe, habe ich jetzt keine Idee mehr.


    Letztes Script unter /administrator/components/com_admin/sql/updates/mysql => 4.1.0-2022-01-24.sql


    Dies ist die Info aus joomla/logs/joomla_update.php:


    Starting installation of new version.
    Finalising installation.
    Start of SQL updates.
    The current database version (schema) is 3.10.0-2021-05-28.
    Ran query from file 4.0.0-2018-03-05. Query text: INSERT INTO `#__extensions` (`name`, `type`, `element`, `folder`, `client_id`, `.
    Ran query from file 4.0.0-2018-03-05. Query text: DELETE FROM `#__extensions` WHERE `type` = 'library' AND `element` = 'phputf8';.
    Ran query from file 4.0.0-2018-03-05. Query text: DELETE FROM `#__extensions` WHERE `type` = 'plugin' AND `element` = 'p3p' AND `f.
    Ran query from file 4.0.0-2018-03-05. Query text: ALTER TABLE `#__user_keys` DROP COLUMN `invalid`;.
    Ran query from file 4.0.0-2018-03-05. Query text: INSERT INTO `#__extensions` (`name`, `type`, `element`, `folder`, `client_id`, `.
    Ran query from file 4.0.0-2018-03-05. Query text: INSERT INTO `#__template_styles` (`template`, `client_id`, `home`, `title`, `inh.
    Ran query from file 4.0.0-2018-03-05. Query text: UPDATE `#__modules` SET `position` = 'status' WHERE `module` = 'mod_version' AND.
    Ran query from file 4.0.0-2018-03-05. Query text: DELETE FROM `#__extensions` WHERE `type` = 'template' AND `element` = 'hathor' A.
    Ran query from file 4.0.0-2018-03-05. Query text: DELETE FROM `#__template_styles` WHERE `template` = 'hathor' AND `client_id` = 1.
    Ran query from file 4.0.0-2018-03-05. Query text: DELETE FROM `#__extensions` WHERE `type` = 'template' AND `element` = 'isis' AND.
    Ran query from file 4.0.0-2018-03-05. Query text: DELETE FROM `#__template_styles` WHERE `template` = 'isis' AND `client_id` = 1;.
    Ran query from file 4.0.0-2018-03-05. Query text: DELETE FROM `#__extensions` WHERE `type` = 'template' AND `element` = 'protostar.
    Ran query from file 4.0.0-2018-03-05. Query text: DELETE FROM `#__template_styles` WHERE `template` = 'protostar' AND `client_id` .
    Ran query from file 4.0.0-2018-03-05. Query text: DELETE FROM `#__extensions` WHERE `type` = 'template' AND `element` = 'beez3' AN.
    Ran query from file 4.0.0-2018-03-05. Query text: DELETE FROM `#__template_styles` WHERE `template` = 'beez3' AND `client_id` = 0;.
    Ran query from file 4.0.0-2018-03-05. Query text: DELETE FROM `#__extensions` WHERE `name` = 'mod_submenu';.
    Ran query from file 4.0.0-2018-03-05. Query text: ALTER TABLE `#__extensions` DROP COLUMN `system_data`;.
    Ran query from file 4.0.0-2018-03-05. Query text: INSERT INTO `#__extensions` (`name`, `type`, `element`, `folder`, `client_id`, `.
    Ran query from file 4.0.0-2018-03-05. Query text: UPDATE `#__menu` SET `link` = 'index.php?option=com_config&view=config' WHERE `l.
    Ran query from file 4.0.0-2018-03-05. Query text: UPDATE `#__menu` SET `link` = 'index.php?option=com_config&view=templates' WHERE.
    Ran query from file 4.0.0-2018-03-05. Query text: ALTER TABLE `#__extensions` ADD COLUMN `changelogurl` text AFTER `element`;.
    Ran query from file 4.0.0-2018-03-05. Query text: ALTER TABLE `#__updates` ADD COLUMN `changelogurl` text AFTER `infourl`;.
    Ran query from file 4.0.0-2018-03-05. Query text: INSERT INTO `#__extensions` (`name`, `type`, `element`, `folder`, `client_id`, `.
    Ran query from file 4.0.0-2018-03-05. Query text: INSERT INTO `#__postinstall_messages` (`extension_id`, `title_key`, `description.
    Ran query from file 4.0.0-2018-03-05. Query text: DELETE FROM `#__extensions` WHERE `type` = 'library' AND `element` = 'idna_conve.
    Ran query from file 4.0.0-2018-03-05. Query text: ALTER TABLE `#__modules` CHANGE `content` `content` TEXT NULL;.
    Ran query from file 4.0.0-2018-05-15. Query text: CREATE TABLE IF NOT EXISTS `#__workflows` ( `id` int NOT NULL AUTO_INCREMENT, .
    Ran query from file 4.0.0-2018-05-15. Query text: INSERT INTO `#__workflows` (`id`, `asset_id`, `published`, `title`, `description.
    JInstaller: :Install: Error SQL Duplicate entry '1' for key 'PRIMARY'
    End of SQL updates - INCOMPLETE.
    Cleaning up after installation.
    Update to version 4.1.0 is complete.

    Hallo Jürgen,

    das ist aber nett, dass du dich um diese Uhrzeit noch meldest!

    Es gibt in der DB verschiedene Prefixe. Ich habe die genannten Tabellen mit dem individuellen Prefix etr_ gelöscht.

    Unter => Global Configuration / Server steht bei mir Database tables => prefix => jsd_

    Diese Tabellen habe ich aber nicht angerührt.


    Offensichtlich ist schon das erste Skript 4.0.0-2018-05-15 nicht vollständig durchgelaufen...


    Grüße,

    Mark

    Hallo Mark,

    Zitat von rendance

    Es gibt in der DB verschiedene Prefixe. Ich habe die genannten Tabellen mit dem individuellen Prefix etr_ gelöscht.

    Unter => Global Configuration / Server steht bei mir Database tables => prefix => jsd_

    Diese Tabellen habe ich aber nicht angerührt.


    Offensichtlich ist schon das erste Skript 4.0.0-2018-05-15 nicht vollständig durchgelaufen...

    Oh je, glaube da liegt wohl der Grund. Wieso verschiedene Prefixe?

    Der "Schaden" ist ja in der jsd_ oder nicht?

    Was meinst Du Jürgen?


    Liebe Grüße

    Christine

    Hmm also laut dem Log welches du oben gepostet hast existiert zu dem Zeitpunkt des Upgrades bereits eine "#__workflows" Tabelle. Dies ist eine 4.x Tabelle welche unter 3.x nicht da sein darf.


    Mein Vorschlag wäre ein Backup von 3.10 wieder einzuspielen und dann noch einmal hier alle Datenbank Tabellen aufzulisten (ggfs. gibt's mehrere Seiten).


    Zitat von rendance

    In der DB habe ich die unter #17 genannten Tabellen gelöscht (#_finder_logging, #_mail_template, #_workflows...... 4 Stück, #_history, wenn vorhanden" gab es bei mir nicht)

    aber trotzdem

    Zitat von rendance

    Ran query from file 4.0.0-2018-05-15. Query text: CREATE TABLE IF NOT EXISTS `#__workflows` ( `id` int NOT NULL AUTO_INCREMENT, .
    Ran query from file 4.0.0-2018-05-15. Query text: INSERT INTO `#__workflows` (`id`, `asset_id`, `published`, `title`, `description.
    JInstaller: :Install: Error SQL Duplicate entry '1' for key 'PRIMARY'

    Das kann nicht sein. Zu dem Zeitpunkt des Upgrades existiert eine #__workflows Tabelle bzw. schon weitere Einträge in dieser Tabelle und deshalb gibt es diese Fehlermeldung.

    Hab´ das jetzt noch mal rausgekramt:

    Lies mal hier ca. ab #27

    Thema
    Update auf Joomla 4 wird durchgeführt endet aber mit Fehler "JInstaller: :Install: SQL-Fehler Duplicate entry '1' for key 'PRIMARY'"
    Ich habe bereits mehrfach versucht, meine Seite in verschiedenen Subdomains testweise auf Joomla 4 upzudaten. Dabei bin ich nach der Anleitung auf joomla.org vorgegangen. Das Update wird auch jeweils durchgeführt, endet aber dann mit der Fehlermeldung lt. Titel. Meiner Meinung nach geht etwas bei der Übertragung der Datenbank schief.
    In der Originalversion wird mir bei Erweiterungen > Verwalten > überprüfen ein Modul "mod_arkquickicon" angezeigt. Das kann ich aber leider nicht durch…
    Reigi

    "Es gibt in der DB verschiedene Prefixe. Ich habe die genannten Tabellen mit dem individuellen Prefix etr_ gelöscht."
    Wenn nur 1 Joomla-Installation auf diese DB zugreift, würde ich die Tabellen mit dem "falschen" Prefix aus der DB löschen. Möglicherweise hast du bei Installationsversuchen 1 DB, aber 2 verschiedene Prefixe angegeben. Kann man machen, aber das wird dann für Ungeübte etwas unübersichtlich.
    Ich würde jetzt zunächst meine 3.x Version solide und fehlerfrei konfigurieren: siehe hier:

    https://docs.joomla.org/Joomla…Step_by_Step_Migration/de

    Gruß Jürgen

    Einmal editiert, zuletzt von Indigo66 () aus folgendem Grund: Ein Beitrag von jsc_01 mit diesem Beitrag zusammengefügt.

    Danke für eure Kommentare und Ideen! Es scheint, dass ich schon seit Jahren unnötigen Ballast in der DB habe.

    Dort habe ich aus Gründen XY (fragt bitte nicht warum...) drei verschiedene Prefixe:

    • etr_
    • jos_
    • jsd_

    Im Backend von 3.10 steht unter => Global Configuration / Server => Database tables => prefix => jsd_


    @Jürgen: nur um auf Nummer sicher zu gehen => ich kann also alle etr- und jos_ Tabellen löschen

    und dann mit dem von dir genannten Schritt (s.u.) weitermachen?


    Dann würde ich das machen und danach sehen, was joomla/logs/joomla_update.php ausspuckt.


    Die Anleitung https://docs.joomla.org/Joomla…Step_by_Step_Migration/de hatte ich gelesen und auch befolgt (aber manchmal steckt der Teufel halt im Detail).


    Schöne Grüße,

    Mark

    Wie ich schon schrieb: wenn du nur diese eine Webseite/Joomla-Installation hast, JA.

    Schau dir dann mal mit phpmyadmin die DB an, da sollten dann ca. 80 Tabellen drinstehen.

    Zitat von rendance

    @Jürgen: nur um auf Nummer sicher zu gehen => ich kann also alle etr- und jos_ Tabellen löschen

    und dann mit dem von dir genannten Schritt (s.u.) weitermachen?

    Langsam: Wenn du das gemacht hast:
    1. Backend aufrufen, DB reparieren, Erweiterungen überprüfen

    2. BACKUP

    3. Erst dann würde ich die beschriebenen Tabellen löschen

    4. Backend aufrufen s. 1. BACKUP

    und jetzt auf Update, ich gehe davon aus, du hast Joomla 3.10.6

    Gruß Jürgen

    Einmal editiert, zuletzt von Indigo66 () aus folgendem Grund: Ein Beitrag von jsc_01 mit diesem Beitrag zusammengefügt.

    Danke, Jürgen, dann habe ich es richtig verstanden. Die von dir zuletzt genannten Schritte hatte ich vor dem letzten Backup von gestern Abend alle schon gemacht. Insofern mache ich mich jetzt ans Löschen der Ballast-Tabellen (aktuell tummeln sich in der DB über 200 Tabellen).

    Ja, ich habe 3.10.6


    Grüße,

    Mark

    ich habe noch 4 Tabellen ohne jsd_ Prefix gefunden:

    • jupgrade_categories
    • jupgrade_menues
    • jupgrade_modules
    • jupgrade_steps

    Sieht nach Joomla Upgrade aus => können die auch gelöscht werden (danach würde ich bei 112 Tabellen insgesamt landen)?


    Grüße,

    Mark

    Einmal editiert, zuletzt von Indigo66 () aus folgendem Grund: Ein Beitrag von rendance mit diesem Beitrag zusammengefügt.

    Hab´jetzt mal spaßeshalber meinen Win10-PC gestartet (zu 99% arbeite ich mit Linux) Xampp mit PHP 8.0.10 und eine Joomla 3.10.4 installiert.


    - auf J3.10.6 aktualisiert + Erweiterungen, Akeeba hat eine neue FEF installiert

    - Überprüfen. Beez3, Beispieldaten und noch 3-4 andere Erweiterungen installiert und diese dann wieder sauber de-installiert.
    - DB reparieren

    - BACKUP durchgeführt

    - SIGE-Galerie gelöscht

    - Erweiterungsprüfung meckert nur noch FOF(Bibliothek) und German Language Pack(Paket) an

    (kannte ich schon)

    - in der DB waren nur noch die #_finder_links_terms Tabellen zu löschen (ca.15-16)

    - Erweiterungen-DB hat ein Problem gemeldet, DB reparieren und gefixt

    - BACKUP

    - UPDATE und alles super

    Guten Abend!

    @Jürgen: Danke für deinen Versuch, das Problem nachzustellen. Das müßtest du vermutlich mit meiner DB machen, um denselben Fehler zu bekommen...


    Hier die letzte Info zum aktuellen Stand der Kunst:

    • ich habe alle Tabellen gelöscht, die nicht das jsd_ Prefix hatten
    • ebenso jsd_ Tabellen, die noch von Kunena (Forum-Erweiterung) kamen, was aber schon lange nicht mehr installiert ist (tauchte unter Erweiterungen verwalten auch nicht mehr auf)
    • außerdem habe ich alle Tabellen nach "kunena", "matukio", "compojoom" (Matukio und Compojoom => Veranstaltungsverwaltung) durchsucht und die entsprechenden Einträge in den Tabellen gelöscht
    • weiterhin habe ich folgende Tabellen gelöscht:
      • jsd_finder_links
      • alle jsd_finder_terms0 bis termsf
      • jsd_workflows
    • anschließend 2x DB reparieren, alles ok, sämtlichen Cache gelöscht
    • Akeeba Backup
    • Migration von 3.10.6 zu 4.1.0 gestartet (immerhin diesmal nicht gleich beim 500er Fehler gelandet)
    • Info aus den letzten Zeilen von joomla_update.php (nur ca. 45 Zeilen durchgelaufen):
      • Ran query from file 4.0.0-2018-05-15. Query text: INSERT INTO `#__workflow_stages` (`id`, `asset_id`, `ordering`, `workflow_id`, `.
      • update JInstaller: :Install: Error SQL Duplicate entry '1' for key 'PRIMARY'
      • update End of SQL updates - INCOMPLETE.
      • update Cleaning up after installation.
      • update Update to version 4.1.0 is complete.
    • Backend 4.1 Meldungen:
      • JInstaller: :Install: Error SQL Duplicate entry '1' for key 'PRIMARY'
      • Table xyz.jsd_history does not exist
      • Unknowen column 'fp.featured_up' in 'field list'

    Ich vermute, dass ich primär das DB-Problem "Error SQL Duplicate entry '1' for key 'PRIMARY' " lösen muss - geht sowas über Funkionalitäten in phpMyAdmin (DB reparieren, ...?)


    Schöne Grüße,

    Mark

    Sorry, wenn ich das jetzt sage, aber du brauchst für das Update eine solide, funktionale Ausgangsversion (J3.10.6) und ein verlässliches Backup.


    Also: Backup noch einmal einspielen, alle jsd_finder_terms0 bis termsf Tabellen löschen nur diese


    DB reparieren


    Im Backend unter Erweiterungen - Überprüfen , wird hier etwas angezeigt?

    Kompatibilitätsprüfung alles Grün?


    Screenshot vom Inhalt der DB (Tabellennamen reichen schon) und stell hier rein.


    Ebenfalls noch lösche: Alle #_workflows, #_workflows_blabla


    wegen:
    CREATE TABLE IF NOT EXISTS `#__workflows` besteht diese Tabelle wird sie NICHT neu mit neuer Struktur angelegt und die INSERTS werden in die veraltete Tabelle versucht, deshalb raucht dein System an dieser Stelle ab.

    Und übrigens: Deine Fehler treten bereits beim 2. von 37 auszuführenden SQL-Scripts auf

    Gruß Jürgen

    Einmal editiert, zuletzt von Indigo66 () aus folgendem Grund: Ein Beitrag von jsc_01 mit diesem Beitrag zusammengefügt.

    Danke für deine Ratschläge, Jürgen. Ich nehme an, dass du mit der soliden Ausgangsversion eine solche meinst, die dann bei der Migration sauber durchläuft - das sehe ich aber leider immer erst nach dem Durchlaufen der Migration. Insofern JA, ich arbeite eigentlich dauernd an der passenden Ausgangsversion!

    Für das Backup nutze ich Akeeba, was hinreichend verläßlich sein sollte ;)


    Erweiterungen - Überprüfen



    Kompatibilitätsprüfung => keine Angaben zur Kompatibilität bei

    • SimplePie Library
    • PKG_JOOMLA Package
    • file_fof30 File
    • flowerbeez Template
    • ja_purity Template
    • go_roundy Template
    • rhuk_milkyway Template
    • FOF Library
    • F0F (NEW) DO NOT REMOVE Library

    Alle gelisteten Elemente der Kompatibilitätsprüfung sind entweder notwendig (FOF) oder templates, die es nicht mehr gibt (nur noch als Joomla-Verzeichnisse) oder sie sind geblockt (SimplePie, PKG_JOOMLA) und damit nicht deinstallierbar.


    Bei beiden Tabellen jsd_finder_tokens bekomme ich mit mit der Funktion Analyze in phpMyAdmin die Meldung "The storage engine for the table doesn't support a... " (vermutlich sollte das "analysis" heißen).


    Ich frage mich immer noch, was ich mit der Meldung INSERT INTO `#__workflow_stages` (`id`, `asset_id`, `ordering`, `workflow_id`, `.update JInstaller: :Install: Error SQL Duplicate entry '1' for key 'PRIMARY'anfangen kann. Es scheint um die Tabelle workflow_stages zu gehen, in der dieser Fehler mit dem Primärschlüssel auftritt, oder? Die könnte ich nochmal zusammen mit den anderen _workflows löschen.Schöne Grüße,Mark

    Zitat von rendance

    jsd_workflow_associations

    jsd_workflow_stages

    jsd_workflow_transitions

    Kannst du löschen


    Zitat von jsc_01

    Ebenfalls noch lösche: Alle #_workflows, #_workflows_blabla


    wegen:
    CREATE TABLE IF NOT EXISTS `#__workflows` besteht diese Tabelle wird sie NICHT neu mit neuer Struktur angelegt und die INSERTS werden in die veraltete Tabelle versucht, deshalb raucht dein System an dieser Stelle ab.

    Und übrigens: Deine Fehler treten bereits beim 2. von 37 auszuführenden SQL-Scripts auf

    Da ich bisher immer direkt auf dem Webhosting-Server gearbeitet habe, möchte ich jetzt doch aus Zeitgründen (es dauert einfach zu lange...) eine lokale Version über xampp laufen lassen.


    Ich habe alles installiert, hänge beim Einspielen des Akeeba Backups aber bei dem Wiederherstellen der DB (localhost:80; mit "[mysql] XAMPP MySQL is already running on port 3306", also Port 3306, haut es erst recht nicht hin).

    Ich habe die DB mit demselben Namen in phpMyAdmin angelegt. Gibt es etwas, was ich übersehen habe?


    nächster Migrationsversuch:

    joomla.update.php => das Skript 4.0.0-2018-07-29 ist nun durchgelaufen, aber 4.0.0-2018-03-05 hängt gleich nach der ersten Zeile "Query text: INSERT INTO `#__extensions` (`name`, `type`, `element`, `folder`, `client_id`, `." mit der Meldung "JInstaller: :Install: Error SQL Unknown column 'system_data' in 'field list' "


    Gute Nacht,

    Mark

    Zitat von rendance

    Ich habe alles installiert, hänge beim Einspielen des Akeeba Backups aber bei dem Wiederherstellen der DB (localhost:80; mit "[mysql] XAMPP MySQL is already running on port 3306", also Port 3306, haut es erst recht nicht hin).

    Da ich mehr mit Lamp als mit XAMPP arbeite weiß ich nur, dass dieser Fehler immer dann auftritt, wenn Skype im Hintergrund läuft und Xampp dann gestartet wird. Beide Tools verwenden den Port 80. Man kan dann den Apache-Port auf 8080 einstellen, oder vorher Skype beenden.

    Das hatte ich auch schon gelesen, Jürgen. Bei mir läuft allerdings Skype (mit sehr großer Sicherheit, werde ich aber heute Abend nochmal überprüfen) nicht im Hintergrund, deshalb stehe ich da gerade auf dem Schlauch. Aber 8080 werde ich spasseshalber mal ausprobieren...


    Grüße,

    Mark