Datenbank-Fehler / Warnung lösen

    Hallo,
    ich sehe schon seit einige Zeit im Backend unter Datenbank folgenden Error

    Code
    Error on rename of './2_hdsports/#sql-4b2f_1a7222' to './2_hdsports/#__content_types' (errno: 150)Error on rename of './2_hdsports/#sql-4b2f_1a7222' to './2_hdsports/#__contentitem_tag_map' (errno: 150)Duplicate key name 'idx_alias'


    Dieser Error kommt auch nach jedem DB-Update. Wisst ihr wie ich das lösen kann? Ich nehme an ich muss manuell in der DB etwas an "idx_alias" ändern


    Zudem zeigt es mir im Backend ein Problem bei DB an:

    Code
    "The Joomla! Core database tables have not been converted yet to UTF-8 Multibyte (utf8mb4)"


    Beides hat offenbar keinen negativen Einfluß auf die Seite, würde ich aber trotzdem gerne lösen können
    LG

    Zitat von Re:Later

    DB-Einstellung in Konfig ist MySQLi ?
    Mysql-Version ist größer/gleich 5.5 (siehe Systeminformationen erster Tab)?
    Reparieren-Button schon geklickt?


    3 x ja :)


    ich glaube der Fehler lässt sich nur über die phpmyadmin lösen (Wie genau ist mir leider nicht klar). Ich denke der Fehler stammt noch aus der Migration von J2 auf J3. Da gab es einige Probleme bei mir.


    Zu UTF8mb4: Das könnte ich ja direkt mit Admin Tools ändern (changing the database collation)?
    Dort sehe ich diese Warning

    Code
    Warning! If you convert your database to the “UTF-8 Multibyte”  collation you MUST have the System - Admin Tools plugin activated to  edit and display multibyte content (such as Emoji). This will no longer be necessary when Joomla! itself includes support for UTF-8 Multibyte.


    Kann man die ignorieren. Ist nun Joomla Standardmäßig UTF-8 Mulitbyte oder nur UTF-8? Dachte eigentlich UTF-8. Aber wenn mir Joomla selbst das Problem anzeigt, das die Seite nicht UTF-8 Multibyte ist, verwirrt das etwas

    Zitat von www.HDsports.at

    Das könnte ich ja direkt mit Admin Tools ändern (changing the database collation)?


    NEIN!
    Es reicht nicht, nur die Kollation zu ändern. Dann solltest du besser auf utf8 bleiben.


    Die relevanten SQL-Dateien findest du in
    administrator/components/com_admin/sql/others/mysql/


    Gibt vielleicht auch einen Trick, Joomla zu veranlassen mit Klick auf Reparieren die Konversion zu starten. Noch nie ausprobiert. Nach Code-Betrachtung:
    Setze in Tabelle #__utf8_conversion den Wert für converted auf 0. Klicke dann Button Reparieren.

    converted war in meiner DB ohnehin auf 0 gestellt.
    Das hilft leider auch nicht weiter...


    Ich weiß leider auch nicht mehr weiter. Ich habe zwar einige englischsprachigen Threads mit ähnlichen Problem gefunden (manche mussten bei "Smart Search" den Index löschen), aber nichts löst mein Problem.

    Ich habe mir mal die Indizes der 2 betroffenen Tabellen mit einer leeren Joomla Installation verglcichen:


    __contentitem_tag_map meiner Webseite


    __contentitem_tag_map Joomla-Neuinstallation


    __content_type meiner Webseite


    __content_type Joomla-Neuinstallation


    bei __content_type gibt es keine Differenzen, bei contentitem_tag_map hingegen schon. Da habe ich viel mehr Einträge. Soll ich die löschen? Könnte die das Problem lösen?


    Zudem ist mir aufgefallen das bei Joomla Neuinstallation alles auf "utf8mb4_unicode_ci" ist während bei meiner Seite utf8_general_ci und utf8mb4_unicode_ci gemischt sind. Wobei die zwei angesprochenen Tabellen sind auch utf8mb4_unicode_ci

    Im Oben genannten Ordner findest du 2 Dateien, endend auf 01 bzw. 02 oder so.


    Die öffnest du in einem Editor und ersetzt alle Vorkommnisse von #__ durch den Seitenprefix deiner Seite, bspw. xyz_


    Speicherst die Dateien und importierst sie in phpMyAdmin (zuvor Datenbank wählen, falls nötig). Erst die 01, dann die 02.


    Abschließend setzt du in Tabelle utf8_converted den Wert auf 2.


    Info: In der 01 siehst du welche Tabellen konvertiert werden. Nicht jede Tabelle muss oder soll konvertiert werden. Die, die bereits konvertiert sind, gehen durch die SQL-Dateien nicht kaputt, sondern es wird noch mal gesetzt.


    Kollationsangaben / Zeichenstzangaben können auch irreführend sein. Bei mir steht bspw. im Joomla-Backend als Kollation / Zeichensatz latin1_swedish_ci, was aber weder die Tabellen noch die Felder darin tangiert, da deren Einstellungen diese grundeinstellung "overrulen". Man muss also immer auf der richtigen Ebene prüfen.


    Weiterhin sind *utf8* und *utf8mb4* weitgehend kompatibel, weshalb viele Erweiterungen auch bei utf8 bleiben, da diese Kollation eben auch für Mysql 5.1 passt. Die müssten also bei der Installation erst ermitteln, ob Mysql utf8mb4 unterstützt. Nicht wirklich dramatisch, aber eben doch AUfwand bzgl. Installer-Script(s).


    Zitat von www.HDsports.at

    Da habe ich viel mehr Einträge. Soll ich die löschen? Könnte die das Problem lösen?


    Löschen solltest du gar nichts. Ist doch logisch, dass eine Seite im Einsatz mehr und / oder anderes in der DB hat als eine frisch installierte.

    ich habe die 2 dateien nun importiert
    bei "utf8_conversion" auf "2" setzen komme ich aber nicht weiter.
    Ich kann die "0" nicht ändern.


    die 0 lässt sich nicht anklicken bzw. editieren


    PS beim Import bekam ich jeweils eine Fehlermeldung
    Die Tabellen existieren allerdings

    Code
    ALTER TABLE `ngie__banners` DROP KEY `idx_metakey_prefix`MySQL meldet: Dokumentation#1146 - Tabelle '2_hdsports.ngie__banners' existiert nicht


    Code
    ALTER TABLE `ngie__banners` MODIFY `alias` varchar(400) NOT NULL DEFAULT ''


MySQL meldet: Dokumentation
#1146 - Tabelle '2_hdsports.ngie__banners' existiert nicht

    Weil du einen doppelten Unterstrich nach dem Prefix ngi in die SQL reingebastelt hast statt nur einen.


    Komisch, dass du den Wert nicht ändern darfst. Wenn das nirgends geht, solltest du mal beim Provider reklamieren. No-Go.


    Wenn du den Reiter SQL oben hast, füge in das große Feld ("SQL-Befehle") ein:

    SQL
    UPDATE `ngie_utf8_conversion`  SET  `converted`  =  '2' ;


    und klicke dann den OK-Button.


    Wenn nicht (auch No-Go), lege eine neue Datei dingsbums.sql an, füge die Zeile ein und importiere dann die Datei.

    Perfekt
    nun steht im Backend "Database table structure is up to date." Schaut also gut aus. Ich bin schon auf das nächste Joomla Update gespannt. Ein Update ohne Fehlermeldung hatte ich schon lange nicht mehr :)


    Zu der Änderung in phpmyadmin: Ich kann eigentlich in allen Tabellen alles ändern, nur diesen einen Wert könnte ich nicht anpassen. Eigenartig...


    Die sache mit _banners kann nicht am doppelten Unterstrich gelegen sein. Denn wenn ich mir die zwei SQL Files ansehe haben die alle zwei Unterstrichte. Kleiner Auszug:

    Code
    ALTER TABLE `ngie__banners` DROP KEY `idx_metakey_prefix`;
ALTER TABLE `ngie__banner_clients` DROP KEY `idx_metakey_prefix`;
ALTER TABLE `ngie__categories` DROP KEY `idx_path`;
ALTER TABLE `ngie__categories` DROP KEY `idx_alias`;
    Zitat von www.HDsports.at

    haben die alle zwei Unterstrichte.


    Dann hast du was falsch gemacht. Man sieht in einem deiner Screenshots, dass bei dir auch nur ein Unterstrich hinter ngi gehört. Außerdem bricht phpMyAdmin bzw. SQL beim ersten Fehler ab und die erste Tabelle ist nun mal in beiden Dateien die ngi_banners bzw. bei dir falsch die ngi__banners .


    Du darfst keinesfalls die 2. Datei einspielen bevor nicht die erste reibungslos durchgelaufen ist!


    Zitat von www.HDsports.at

    nun steht im Backend "Database table structure is up to date."


    Das ist kein Wunder, wenn du den Wert auf 2 gesetzt hast ;) Bedeutet aber nichts, da du es wie gesagt falsch gemacht hast.


    Mach's noch mal. Weiß der Teufel, was bei dir jetzt rausgekommen ist.

    Jetzt erhalte ich eine andere Fehlermeldung

    Code
    Der Import wurde erfolgreich abgeschlossen, 20 Abfragen wurden ausgeführt. (utf8mb4-conversion-01.sql)
Fehler


SQL-Befehl:


ALTER TABLE `ngie_content_types` DROP KEY `idx_alias`
    MySQL meldet: 
#1553 - Kann Index 'idx_alias' nicht löschen: wird für eine Fremdschlüsselbeschränkung benötigt


    Über "#1553 - Kann Index nicht löschen: wird für eine Fremdschlüsselbeschränkung benötigt" finde ich absolut gar nichts über google

    mhm, leider wieder ein Fehler beim Import der ersten sql datei

    Code
    ALTER TABLE `ngie_banners` DROP KEY `idx_metakey_prefix`    MySQL meldet: #1091 - Kann 'idx_metakey_prefix' nicht löschen. Existiert die Spalte oder der Schlüssel?


    Bei mir fehlt dieser Eintrag in den Indizes dieser Tabelle:

    Code
    idx_metakey_prefix BTREE Nein Nein metakey_prefix 0 A Nein


    Bei einer Leeren Joomla-Installation ist dieser vorhanden


    Klicke ich bei metakey in der Struktur auf Index erhalte ich diese Fehlermeldung

    Code
    ALTER TABLE `ngie_banners` ADD INDEX(` metakey `);
1170 - BLOB- oder TEXT-Spalte 'metakey' wird in der Schlüsseldefinition ohne Schlüssellängenangabe verwendet

    Beim letzten Lauf wurde der Index gelöscht, jetzt ist er natürlich weg und kann nnicht erneut gelöscht werden.


    Hast du diesen Tabulator?


    Dann füge die Zeilen der ersten Datei dort einzeln ein und klicke jeweils OK.


    Die Zeilen Jeweils umgeben mit den beiden Zeilen zur Fremdschlüsselprüfung.
    Also z.B.

    Code
    SET FOREIGN_KEY_CHECKS=0;
ALTER TABLE `ngie_banners` DROP KEY `idx_metakey_prefix`;
SET FOREIGN_KEY_CHECKS=1;


    Dann können dir die auftretenden Fehler bzgl. löschen geht nicht, weil nicht exist. wurst sein und nimmst halt die nächste Zeile.


    Das wars jetzt von mir. Bitte wende dich an deinen Provider fc-hosting.

    Mir fallen noch zwei Sachen ein, die du versuchen könntest:

    • Du könntest ein AkeebaBackup machen und versuchen es, zum testen auf einer Subdomain und einer 2ten Datenbank, mit dem Kickstarter wieder zu installieren. Beim MySQL-Teil kannst du unter den erweiterten Einstellungen entweder utf8 zurücksetzen (erzwingen) oder wenn möglich auf utf8mb4 umstellen.
      Wenn es klappt, kannst du ja erneut ein Backup machen und live wieder einspielen.
    • Du könntest unter Komponenten -> Joomla! aktualiseren neu suchen lassen und die Version noch einmal komplett drüber installieren lassen.
    Zitat von www.HDsports.at

    Geht leider auch nicht, egal für welche Tabelle ich das mache ich erhalte immer die Fehlermeldung zum Befehl der Tabelle


    Lies doch bitte etwas genauer. Ignoriere dann diese Fehler und geh zur nächtsen Zeile über. Steht doch oben.
    Sieh treten auf, weil der Schritt bereits getan ist!


    Zitat von Re:Later

    Dann können dir die auftretenden Fehler bzgl. löschen geht nicht, weil nicht exist. wurst sein und nimmst halt die nächste Zeile.

    Sorry, für das späte Wiedereröffnen

    Zu den 2 Dateien: utf8mb4-conversion-01 und utf8mb4-conversion-02

    weil ich wie oben erwähnt immer wieder Fehler erhalten habe, habe ich alles immer Schrittweise importiert und die Zeilen gelöscht die Fehler verursacht haben.

    Nachdem ich alles importiert habe und ngie_utf8_conversion wieder auf 0 gesetzt habe und auf Datenbank repariert habe, das selbe Problem wie bisher:


    Code
    Fehler Error on rename of './2_hdsports/#sql-df3_118b00' to './2_hdsports/#__content_types' (errno: 150)
 Error on rename of './2_hdsports/#sql-df3_118b00' to './2_hdsports/#__contentitem_tag_map' (errno: 150)
 Duplicate key name 'idx_alias'


2 Datenbankprobleme gefunden!                                                                                                                                                        
Die Tabelle „'ngie_ucm_content'“ hat den falschen Typ oder die falschen Attribute für die Spalte „'core_title'“ mit Typ „varchar(400)“. (Von Datei: „3.7.0-2017-01-08.sql“.)                                                                                Die Joomla-Core-Datenbanktabellen wurden bis jetzt noch nicht in UTF-8 Multibyte (utf8mb4) konvertiert.


    Ich hatte bei content_types und contentitem_tag_map auch immer Fehermeldungen beim Import der Code-Zeilen aus utf8mb4-conversion-01 und utf8mb4-conversion-02

    Also ich nehme mal an das ich an den Tabellen manuell etwas ändern muss