Unfassbar, dass die Kunden das selbst ausbügeln sollen!
Ich würde überlegen, ob man in diesem Fall nicht sogar Schadenersatz einklagen kann.
Unfassbar, dass die Kunden das selbst ausbügeln sollen!
Ich würde überlegen, ob man in diesem Fall nicht sogar Schadenersatz einklagen kann.
Ein Hosting Umzug wäre meine Lösung.
Das habe ich gemacht nachdem HostEurope von GoDaddy aufgekauft wurde.
Gruß, kdh
Das habe ich gemacht nachdem HostEurope von GoDaddy aufgekauft wurde.
Gruß, kdh
Satire:
heißen die jetzt nicht GoNixmehr ?
Hallo alle,
Hosteurope will morgen voraussichtlich eine Lösung ausrollen, da es einen Bug in der aktuellen mySQL-Version mit der eingesetzten Hardware gibt.
lg daniel
8.3 kann ich bei HE noch nicht auswählen.
Schade. Wäre zur Fehlereingrenzung wünschenswert.
Auf 8.2 umstellen ist schon geplant, aber jetzt mit Fehler, werde ich das nicht umstellen.
Aktiviere dazu den Call Stack.
Da kann man die möglichen Problemquellen erkennen.
Solange HE das Datenbankproblem nicht gelöst hat sollte man meiner Meinung nach wohl besser möglichst keine Änderungen an produktiven Joomla Website´s vornehmen weil möglicherweise für die Katz oder sogar schädlich.
Besser ist es wohl, für alle Fälle, bereits vorhandene vollständige Backups lokal zu sichern...
Hallo alle,
Hosteurope will morgen voraussichtlich eine Lösung ausrollen, da es einen Bug in der aktuellen mySQL-Version mit der eingesetzten Hardware gibt.
lg daniel
Danke für das Update!
Backup woanders sichern kann ich in dem Fall auch nur empfehlen!!!
Unfassbar, dass die Kunden das selbst ausbügeln sollen!
Ich würde überlegen, ob man in diesem Fall nicht sogar Schadenersatz einklagen kann.
Momentan laufen sie darauf hinaus gegen ihre SLA zu verstossen bezüglich servererreichbarkeit
Hallo alle,
Hosteurope will morgen voraussichtlich eine Lösung ausrollen, da es einen Bug in der aktuellen mySQL-Version mit der eingesetzten Hardware gibt.
lg daniel
saardaniel woher weisst du das?
Alles anzeigenUnsere Lösung:
Bei Hosteurope die Datenbank mit phpmyadmin verwaltet, die Tabelle #_updates komplett gelöscht und manuell neu angelegt. Dazu diesen SQL-Befehl benutzt ("#" muss natürlich durch das richtige Präfix ersetzt werden):
CREATE TABLE `#_updates` (
`update_id` int NOT NULL,
`update_site_id` int DEFAULT '0',
`extension_id` int DEFAULT '0',
`name` varchar(100) DEFAULT '',
`description` text NOT NULL,
`element` varchar(100) DEFAULT '',
`type` varchar(20) DEFAULT '',
`folder` varchar(20) DEFAULT '',
`client_id` tinyint DEFAULT '0',
`version` varchar(32) DEFAULT '',
`data` text NOT NULL,
`detailsurl` text NOT NULL,
`infourl` text NOT NULL,
`extra_query` varchar(1000) DEFAULT ''
) ENGINE=MyISAM DEFAULT CHARSET=utf8mb3 COMMENT='Available Updates';--
-- Indizes der exportierten Tabellen
----
-- Indizes für die Tabelle `#_updates`
--
ALTER TABLE `#_updates`
ADD PRIMARY KEY (`update_id`);--
-- AUTO_INCREMENT für exportierte Tabellen
----
-- AUTO_INCREMENT für Tabelle `kceh8_updates`
--
ALTER TABLE `#_updates`
MODIFY `update_id` int NOT NULL AUTO_INCREMENT;
COMMIT;/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;
/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;
/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;
Hallo,
ich bin diesen Weg heute auch gegangen.
1. phpmyadmin aufrufen.
2. Tabellenübersicht anzeigen lassen, Tabelle markieren und löschen
3. SQL für die Tabelle '_updates' aus den Backups geholt und eingespielt.
4. System läuft erstmal normal ohne Fehler
5. Weiteres Backup angelegt bevor ich erneut irgendwo klicke.
Ich bin gespannt, ob bei erneutem Klicken, die Fehler wieder entstehen und gebe Bescheid.
viele Grüße
ich bin diesen Weg heute auch gegangen.
Müsst ihr das echt alles selbst lösen bei Hosteurope?
Danke für das Update!
Backup woanders sichern kann ich in dem Fall auch nur empfehlen!!!
Danke für den Hinweis Sigrid, gute Idee
Vielleicht hätte doch mal jemand #18 lesen sollen.
Alles anzeigenHallo,
ich bin diesen Weg heute auch gegangen.
1. phpmyadmin aufrufen.
2. Tabellenübersicht anzeigen lassen, Tabelle markieren und löschen
3. SQL für die Tabelle '_updates' aus den Backups geholt und eingespielt.
4. System läuft erstmal normal ohne Fehler
5. Weiteres Backup angelegt bevor ich erneut irgendwo klicke.
Ich bin gespannt, ob bei erneutem Klicken, die Fehler wieder entstehen und gebe Bescheid.
viele Grüße
ayko, vielenDank und an tomkoeller , ich finde es jedoch unglaublich, dass wir das selber machen sollen bzw. von HE nach 6 Tagen immer noch keine STABILE Lösung da ist.
aykobitte berichte ob das Szenario danach erneut auftritt.
2 meiner domains hatte HE ja "repariert" was nach 2. Aufrufen des Buttons (erweiterungen aktualisieren / prüfen) auch wieder dahin war.
VG
saardaniel woher weisst du das?
Durch einen Anruf.
lg daniel
Hi zusammen,
es gibt ein update: Heute nacht wird es eine Wartung durch HE geben. Demnach ist die Reparatur #71 + #60 (durch HE oder selbst) via phpmyadmin der *update Tabelle nicht effektiv bzw. erfolgsversprechend.
HE informiert gerade per email darüber - solltet ihr betroffen sein solltet ihr euch bei HE melden damit ihr auch gewartet werden könnt.
Wie es bei mir morgen aussieht: Ich werde berichten.
VG!
solltet ihr euch bei HE melden damit ihr auch gewartet werden könnt.
Muss man das für jedes Paket selber machen/beantragen?
ayko, vielenDank und an tomkoeller , ich finde es jedoch unglaublich, dass wir das selber machen sollen bzw. von HE nach 6 Tagen immer noch keine STABILE Lösung da ist.
aykobitte berichte ob das Szenario danach erneut auftritt.
2 meiner domains hatte HE ja "repariert" was nach 2. Aufrufen des Buttons (erweiterungen aktualisieren / prüfen) auch wieder dahin war.
VG
flusen Danke für deine Infos.
Update bei mir. Nachdem ich vorsichtshalber noch eine Sicherung gemacht habe, ist danach beim Extensions-update-klick alles gut gegangen. Ebenso Update auf 5.2.2.
Trat also nicht erneut auf.
Was ja nun hinfällig ist, durch die Rundmail von Hosteurope.
Viele Grüße und Gute Nacht.