Fehler 1050 bei Update von 2.5.28 auf 3.4.3

1050 - Es ist ein Fehler aufgetreten


Table 'qmupy_postinstall_messages' already exists SQL=CREATE TABLE `qmupy_postinstall_messages` ( `postinstall_message_id` bigint(20) unsigned NOT NULL AUTO_INCREMENT, `extension_id` bigint(20) NOT NULL DEFAULT '700' COMMENT 'FK to #__extensions', `title_key` varchar(255) NOT NULL DEFAULT '' COMMENT 'Lang key for the title', `description_key` varchar(255) NOT NULL DEFAULT '' COMMENT 'Lang key for description', `action_key` varchar(255) NOT NULL DEFAULT '', `language_extension` varchar(255) NOT NULL DEFAULT 'com_postinstall' COMMENT 'Extension holding lang keys', `language_client_id` tinyint(3) NOT NULL DEFAULT '1', `type` varchar(10) NOT NULL DEFAULT 'link' COMMENT 'Message type - message, link, action', `action_file` varchar(255) DEFAULT '' COMMENT 'RAD URI to the PHP file containing action method', `action` varchar(255) DEFAULT '' COMMENT 'Action method name or URL', `condition_file` varchar(255) DEFAULT NULL COMMENT 'RAD URI to file holding display condition method', `condition_method` varchar(255) DEFAULT NULL COMMENT 'Display condition method, must return boolean', `version_introduced` varchar(50) NOT NULL DEFAULT '3.2.0' COMMENT 'Version when this message was introduced', `enabled` tinyint(3) NOT NULL DEFAULT '1', PRIMARY KEY (`postinstall_message_id`) ) DEFAULT CHARSET=utf8;

Diesen Fehler bekomme ich bei o.g. Update.
Kann mir jemand einen Tipp geben wo das Problem liegt bzw. ob noch etwas in diesem Zustand zu retten ist?
Im Kontrollzentrum bin ich noch, aber abmelden geht nicht und auch sonst leider nicht viel
Backup einspielen ist kein Problem, nur wenn ich nicht weiß wo mein Fehler ist ... weiß ich dann auch nicht weiter
Vielen Dank vorab.

Zitat von Re:Later

Wenn ich im andern Thread richtig verstanden habe, hast du bereits ein Backup angestoßen, dass wegen Dateirechten nicht abgeschlossen wurde.

Die Backups liefen immer ohne Probleme wieder rein.
Inzwischen wurde das Backup auch wieder eingespielt und ja, das Update lief diesmal schon ganz schön weit durch.
Nun habe ich eine Vermutung zu diesem Fehler.
Beim allerersten Update-Versuch war u.a. eine Fehlermeldung, dass die Tabelle qmupy_postinstall_messages nicht erstellt werden konnte.
Ein Tipp aus dem Netz: Tabelle einfach selbst entsprechend anlegen.
Das hatte ich getan und zumindest dieser Fehler war weg. Aber ansonsten schien damals aber nicht viel gelaufen zu sein und ich bin zurück.
Jetzt hatte ich vor dem Update diese Tabelle manuell angelegt.
Kann genau das diesmal mein Fehler gewesen sein?

Hm, irgendetwas ist seltsam.
Jetzt nach dem das Backup wieder eingespielt ist, gibt es die Tabelle "qmupy_postinstall_messages" schon und ich geh davon aus, dass auch die DB zurückgespielt wurde (ich mach das nicht, kann das nicht selbst, macht nur der Hoster).
Wie wichtig bzw. was hat es eigentlich mit dieser Tabelle auf sich?
Bisher habe ich dazu gelesen, dass die angelegt wird bei einem Abbruch des Updates?

Auf jeden Fall hab ich das Update vorerst verschoben und teste nun alles zum x.ten Mal lokal (da hatte ich bisher noch nicht einmal ein derartiges Problem).

Zitat von Re:Later

Hab mich da bisher hier im Thread zurückgehalten, aber jetzt halt doch die Empfehlung, den Hoster zu wechseln. Ich kenne auch so kleinere, die Kunden von mir "lieb gewonnen haben", die überall die Hand drauf halten, blockieren, unübliche Konfigurationen "aus Sicherheitsgründen" haben, bestimmte Dinge nicht installiert haben, die das Seitenbetreiberleben extrem erleichtern.
Oder eben Kunden nicht selbst an die Datenbank lassen. Das ist mit Anleitung, z.B. von jemand hier im Forum, nicht so schwer eine Tabelle zu löschen.

Oh oh, ehe ich einen phpMyAdmin-Zugang hatte ... aber den hab ich und ich kenn mich da auch bissel aus

Zitat von Re:Later

Die Tabelle dient dem Speichern von Nachrichten, die nach Joomlaupdates, aber auch paar Erweiterungen, zur Anzeige kommen. Sie wurde in Joomla3 eingeführt und gehört zu Joomla, ohne weitere Probleme geht es nicht ohne. Aber, wenn sie eben ein zerschossenes Update blockiert, weil sie erneut angelegt werden soll und schon da ist, dann kann man sie problemlos löschen.

da staune ich nun aber doch, dass es diese Tabelle nach dem Einspielen des Backups noch gibt Diese sollte ich also unbedingt vor einem erneuten Versuch löschen.

Zitat von Re:Later

Wenn es lokal klappt und du nicht ganz so fit bist, dann verwende Akeeba-Backup zum sichern deines lokalen, geupdateten Joomlas. Mit dem Tool Akeeba Kickstart, kannst du das Joomla dann auf dem Server installieren. Bei deinem Hoster sehe ich allerdings irendwie schwarz. Du brauchst mindestens die Zugangsdaten für die Datenbank, die dann automatisch von Kickstart angelegt wird; und Akeeba Kickstart braucht volle Schreibrechte für den Webspace. Bei "normalen" Providern für die "normale" Webseite wird das durch CGI (fastcgi, fcgi) gewährleistet.

Leider kann ich mir lokal nicht die ganze Joomla-Installation sichern. Wir haben so in etwa an die 20 - 30.000 Bilder drin und das bekomme ich schon kaum in akzeptabler Zeit zum Download, geschweige denn wieder zum Upload.
Auch schon deshalb bin ich auf die Mithilfe des Hosters (leider) angewiesen.
Liebend gern würde ich das alles selbstständig mit Akeeba machen, da ich das Tool echt super finde.

Zitat von Re:Later

2.) kannst du den Bilderordner unberührt auf dem Server lassen, kopierst den Rest und Datenbank auf lokal herunter. Machst Update und Akeeba-Backup, lebst damit, dass im Frontend die Bilder fehlen. Löscht auf dem Server die Ordner, außer nicht lokal kopierte Bilderordner. Machst Akeeba Kickstart, das bestehende Ordner und Dateien dabei nicht überschreibt, soweit sie im Archiv nicht enthalten sind.

Das klingt für micht sehr gut.
Bisher hatte ich immer Bedenken, dass mir der Kickstart die JoomGallery-Verzeichnisse, welche nicht im Akeeba-Archiv enthalten sind löscht.
Vielen Dank!