Fehler bei Update 4.8.15 - 4.8.18

[sandra07]

Hallo zusammen

Beim Update von 4.8.15 oder 4.8.16 nach 4.8.18 habe ich folgende Fehlermeldungen bei den Schritten 10, 11, und 32:

Code: Alles auswählen

[26-Feb-2013 09:53:52] /setup/dbupdate.php?step=10 MySQL error 1068: Multiple primary key defined
  ALTER TABLE con_upl_meta ADD PRIMARY KEY (id_uplmeta) 
[26-Feb-2013 09:53:53] /setup/dbupdate.php?step=11 MySQL error 1068: Multiple primary key defined
  ALTER TABLE con_online_user ADD PRIMARY KEY (user_id) 
[26-Feb-2013 09:53:53] /setup/dbupdate.php?step=11 MySQL error 1068: Multiple primary key defined
  ALTER TABLE con_file_information ADD PRIMARY KEY (idsfi) 
[26-Feb-2013 09:53:58] /setup/dbupdate.php?step=32 MySQL error 1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '100' at line 1
SHOW COLUMNS FROM 100
[26-Feb-2013 09:53:58] /setup/dbupdate.php?step=32 next_record called with no query pending.
[26-Feb-2013 09:53:58] /setup/dbupdate.php?step=32 MySQL error 1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '103' at line 1
SHOW COLUMNS FROM 103
[26-Feb-2013 09:53:58] /setup/dbupdate.php?step=32 next_record called with no query pending.
[26-Feb-2013 09:53:58] /setup/dbupdate.php?step=32 MySQL error 1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '107' at line 1
SHOW COLUMNS FROM 107
[26-Feb-2013 09:53:58] /setup/dbupdate.php?step=32 next_record called with no query pending.
[26-Feb-2013 09:53:58] /setup/dbupdate.php?step=32 MySQL error 1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '111' at line 1
SHOW COLUMNS FROM 111
[26-Feb-2013 09:53:58] /setup/dbupdate.php?step=32 next_record called with no query pending.
[26-Feb-2013 09:53:58] /setup/dbupdate.php?step=32 MySQL error 1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '116' at line 1
SHOW COLUMNS FROM 116
[26-Feb-2013 09:53:58] /setup/dbupdate.php?step=32 next_record called with no query pending.
[26-Feb-2013 09:53:58] /setup/dbupdate.php?step=32 MySQL error 1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '119' at line 1
SHOW COLUMNS FROM 119
[26-Feb-2013 09:53:58] /setup/dbupdate.php?step=32 next_record called with no query pending.
[26-Feb-2013 09:53:58] /setup/dbupdate.php?step=32 MySQL error 1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '122' at line 1
SHOW COLUMNS FROM 122
[26-Feb-2013 09:53:58] /setup/dbupdate.php?step=32 next_record called with no query pending.
[26-Feb-2013 09:53:58] /setup/dbupdate.php?step=32 MySQL error 1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '125' at line 1
SHOW COLUMNS FROM 125
[26-Feb-2013 09:53:58] /setup/dbupdate.php?step=32 next_record called with no query pending.
[26-Feb-2013 09:53:58] /setup/dbupdate.php?step=32 MySQL error 1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '128' at line 1
SHOW COLUMNS FROM 128
[26-Feb-2013 09:53:58] /setup/dbupdate.php?step=32 next_record called with no query pending.
[26-Feb-2013 09:53:58] /setup/dbupdate.php?step=32 MySQL error 1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '131' at line 1
SHOW COLUMNS FROM 131
[26-Feb-2013 09:53:58] /setup/dbupdate.php?step=32 next_record called with no query pending.
[26-Feb-2013 09:53:58] /setup/dbupdate.php?step=32 MySQL error 1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '136' at line 1
SHOW COLUMNS FROM 136
[26-Feb-2013 09:53:58] /setup/dbupdate.php?step=32 next_record called with no query pending.
[26-Feb-2013 09:53:58] /setup/dbupdate.php?step=32 MySQL error 1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '140' at line 1
SHOW COLUMNS FROM 140
[26-Feb-2013 09:53:58] /setup/dbupdate.php?step=32 next_record called with no query pending.
[26-Feb-2013 09:53:58] /setup/dbupdate.php?step=32 MySQL error 1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '145' at line 1
SHOW COLUMNS FROM 145
[26-Feb-2013 09:53:58] /setup/dbupdate.php?step=32 next_record called with no query pending.
[26-Feb-2013 09:53:58] /setup/dbupdate.php?step=32 MySQL error 1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '149' at line 1
SHOW COLUMNS FROM 149
[26-Feb-2013 09:53:58] /setup/dbupdate.php?step=32 next_record called with no query pending.
[26-Feb-2013 09:53:58] /setup/dbupdate.php?step=32 MySQL error 1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '153' at line 1
SHOW COLUMNS FROM 153
[26-Feb-2013 09:53:58] /setup/dbupdate.php?step=32 next_record called with no query pending.
[26-Feb-2013 09:54:00] /setup/dbupdate.php?step=32 MySQL error 1061: Duplicate key name 'idclient'


ALTER TABLE con_file_information ADD INDEX idclient(idclient)
[26-Feb-2013 09:54:00] /setup/dbupdate.php?step=32 MySQL error 1061: Duplicate key name 'type'

ALTER TABLE con_file_information ADD INDEX type(type)
[26-Feb-2013 09:54:00] /setup/dbupdate.php?step=32 MySQL error 1061: Duplicate key name 'filename'

Auswirkungen habe ich bis jetzt noch keine bemerkt. Frontend und Backend läuft!
Jemand eine Idee was das für Fehler sind?

Schonmal herzlichen Dank!

[xmurrix]

Hallo Sandra07,

die Einträge wegen "ALTER TABLE" kannst du im Grunde ignorieren, da hier jedes Mal versucht wurde ein schon vorhandenes Feld anzulegen.

Die Zeilen mit

Code: Alles auswählen

SHOW COLUMNS FROM ...

sind ungewöhnlich, etwas in der Art ist mir bisher nicht untergekommen, daher kann ich dir dazu nichts genaueres sagen.

Auch wenn das Backend und das Frontend fehlerfrei laufen, wäre es bestimmt nicht schlecht, die Datenbank zu prüfen.

Ob alles in Ordnung ist, kannst du folgendermaßen feststellen:

• Installiere eine neue CONTENIDO Instanz auf dem gleichen Server, z. B. unter einer Subdomain mit einer neuen Datenbank.
• Exportiere die Datenbanken (nur die Struktur, nicht Daten) beider CONTENIDO Installationen
• Vergleiche die Tabellen und Felder beider Exporte mit einem Merge-Tool, z. B. WinMerge. Sollte irgend etwas schief gegangen sein, wirst du das beim Vergleich erkennen können.

Gruß
xmurrix

[sandra07]

Hallo xmurrix
Dieselben Fehler habe ich nun schon bei 15 verschiedenen Installationen, scheint also kein Einzelfall zu sein.
Werde das mit der Datenbankprüfung nächste Woche in Angriff nehmen, danke für den Tipp!

[Spider IT]

Hallo Murat,

die Einträge wegen "ALTER TABLE" kannst du im Grunde ignorieren, da hier jedes Mal versucht wurde ein schon vorhandenes Feld anzulegen.

richtig lesen wäre hilfreich.

Code: Alles auswählen

[26-Feb-2013 09:53:52] /setup/dbupdate.php?step=10 MySQL error 1068: Multiple primary key defined
  ALTER TABLE con_upl_meta ADD PRIMARY KEY (id_uplmeta)

Es geht hier nicht um ein neues Feld, sondern um eins dass auf PRIMARY KEY umgestellt werden soll, das aber nicht kann, weil "Duplikate" vorhanden sind (mehrere gleiche Primärschlüssel sind nun mal nicht erlaubt).

Gruß
René

[sandra07]

Hallo zusammen
Ich habe nun eine neue Contenido Instanz auf gleichem Server, wie vorgeschlagen, installiert und konnte nichts feststellen. Die leeren Tabellen sehen gleich aus. Wäre vielleicht noch interessant zu wissen was denn Step 32 überhaupt ist? Kann man das irgendwo feststellen?
Danke schonmal...

[Oldperl]

Hallo Sandra,

ich denke nicht, daß das mit den Tabellen in der DB zu tun hat. Die Meldung

Code: Alles auswählen

SHOW COLUMNS FROM 100

zeigt, das hier irgendwo falsch zugegriffen wird, denn dort sollte eigentlich ein Tabellenname und keine Zahl stehen. Man sollte nochmal prüfen ob das Setup auch auf die korrekte DB zugreift.

...was denn Step 32 überhaupt ist? Kann man das irgendwo feststellen?

Die angegebenen "Steps" geben den Schritt bzw. die Anzahl der erfolgten Aufrufe der Update-Datei an. Die Daten werden schrittweise vom Setup in die DB geschrieben um Zeitüberschreitungen, Timeout des Scripts, zu vermeiden. Diese Schritte können je nach Anzahl der Daten im Setup variieren. Zumindest bis zur 4.8.15 gab es kein Debugging-Feature dafür, ob es sowas inzwischen für die 4.8.18 gibt kann ich nicht sagen, möchte ich aber bezweifeln. Man benötigt es auch eigentlich auch nicht wenn alles passt, und um sowas wie bei Dir zu prüfen reicht eine einfache Ausgabe des Scripts.

Gruß aus Franken

Ortwin

[xmurrix]

Hallo sandra07,

habe mir gerade das setup von 4.8.15 und 4.8.18 angesehen, sehe da keine gravierenden Änderungen, die dein Problem erklären würden. Sehr wahrscheinlich gibt es ein Problem beim Aufruf der Funktion dbUpgradeTable() in der setup/dbupdate.php.
Die Schritte werden dynamisch ermittelt, also Anzahl der SQL-Statements für die Datenbank geteilt durch 50 (oder so ähnlich).

Schau dir am Besten an, was da beim Aufruf von dbUpgradeTable() in der setup/dbupdate.php passiert.

Darin kommt dbUpgradeTable() zwei mal vor:

Code: Alles auswählen

dbUpgradeTable($db, $_SESSION["dbprefix"] . "_" . $data[0], $data[1], $data[2], $data[3], $data[4], $data[5], $data[6], "", $drop);

Du kannst auch in der setup/templates/setup/forms/installer.tpl das iframe, in der die einzelnen Schritte ausgeführt werden, sichbar machen. Ändere die Zeile

Code: Alles auswählen

<iframe style="width: 500px; height: 100px; visibility:hidden;" src="{DBUPDATESCRIPT}"></iframe>

in

Code: Alles auswählen

<iframe style="width: 500px; height: 100px;" src="{DBUPDATESCRIPT}"></iframe>

Dann kannst du eventuelle Meldungen im iframe sehen oder eigene Debugausgaben gegenprüfen.

Wichtig wäre es auch zu wissen, was für eine MySQL/PHP Version da läuft und welche Storage Engine in MySQL verwendet wird.

Und gibt es eine besondere Vorgeschichte zur der CONTENIDO Installation, wie z. B. Update von 4.6 auf 4.8 usw...?

Gruß
xmurrix

[sandra07]

Hallo
Kann ich das Setup mit dem geänderten install.tpl einfach nochmals ausführen?
Zum Teil sind es Contenido Installationen die schon älter und mehrmals geupatet worden sind (u.a. Version 4.6). Es sind aber auch neu installierte Versionen 4.8.15. Bei einem einzigen Update hatte ich die Fehler nicht, ich glaube das war eine Version 4.8.16, bin mir aber nicht mehr ganz sicher.
Datenbank MySQL 5.1.53, PHP 5.2.17

[xmurrix]

...Kann ich das Setup mit dem geänderten install.tpl einfach nochmals ausführen?...

Ja, aber bin mir jetzt nicht sicher ob du das Update erneut machen kannst oder ob nur Migraton möglich ist und in wieweit die Migration die Datenbakstruktur abgleicht und anpasst. Die Migration ist mehr zum Anpassen der Pfade bei einem Serverwechsel gedacht.
Mach aber vorher immer eine DB-Sicherung.

...Datenbank MySQL 5.1.53, PHP 5.2.17...

In welchem Moduls läuft die MySQL Datenbank und welche Engine verwendet es? Vielleicht kann man darüber erfahren, wieso das Update bei dir nicht klappt?

Falls der Provider zuvor ein Update von MySQL und oder PHP gemacht hat, kann das auch eine Ursache dafür sein.

[sandra07]

Was heisst konkret "in welchen Moduls"? Der mysql-server unterstützt myisam und innodb und ist bei allen Installationen identisch.
Wenn das unsicher ist mit dem nochmaligen Update, verzichte ich lieber, denn das sind alles Kunden Sites!
Nochmals danke schonmal....

[xmurrix]

Ich meine folgendes:
http://dev.mysql.com/doc/refman/5.1/de/ ... -mode.html

Je nach Modus verhält sich der Server etwas anders. Es kann durchaus Möglich sein, dass sich etwas vor dem Update auf 4.8.18 am MySQL-Server geändert hat und dies unbemerkt bleibt oder keine negativen Auswirkungen hat.

CONTENIDO macht im Betrieb in der Regel keine Änderungen an der Datenbankstruktur. Nicht aber das Update, beim Update kann es passieren, dass neue Felder oder Indizies hinzukommen oder entfernt werden. Und wenn da der SQL-Mode zu strikt eingestellt ist, kann es sein, dass Änderungen an der DB-Struktur nicht übernommen werden können.

...Wenn das unsicher ist mit dem nochmaligen Update, verzichte ich lieber, denn das sind alles Kunden Sites!...

Stimmt, bei Produktivseiten sollte man nicht rumspielen. Dennoch solltest du prüfen, ob das Update auf Datenbankebene wie gewünscht funktioniert hat. Wenn das Update der DB nicht vollständig durchläuft, kann es passieren, das manche Bereiche in CONTENIDO nicht wie gewüscht funktionieren. Das ist auch nicht gut.

Installiere CONTENIDO 4.8.18 auf einer Subdomain auf dem Server, exportiere die Datenbank ohne Daten, dann exportiere die Datenbank der Kundenseiten ohne Daten. Damit hast du zwei SQL-Exporte, die du miteinander vergleichen kannst.

Das Problem kann auch ganz woanders liegen, man muss halt schauen, was alles in betracht kommt, oder auch nicht...

[sandra07]

Ich meine folgendes:
http://dev.mysql.com/doc/refman/5.1/de/ ... -mode.html

Alle sind auf demselben Server ohne Angabe von SQL Modus, den könnte ich setzen, falls es das braucht.

CONTENIDO macht im Betrieb in der Regel keine Änderungen an der Datenbankstruktur. Nicht aber das Update, beim Update kann es passieren, dass neue Felder oder Indizies hinzukommen oder entfernt werden. Und wenn da der SQL-Mode zu strikt eingestellt ist, kann es sein, dass Änderungen an der DB-Struktur nicht übernommen werden können.

Dann müssten alle die Fehler gehabt haben. Bei einem hatte ich keine Fehler.

Installiere CONTENIDO 4.8.18 auf einer Subdomain auf dem Server, exportiere die Datenbank ohne Daten, dann exportiere die Datenbank der Kundenseiten ohne Daten. Damit hast du zwei SQL-Exporte, die du miteinander vergleichen kannst.

Das habe ich bereits getan und konnte nichts feststellen was anders ist (ausser die Reihenfolge der Tabellen)

[xmurrix]

Solange das nicht reproduzierbar oder die Ursache nicht genau bekannt ist, können wir hier leider nicht viel machen.

...Das habe ich bereits getan und konnte nichts feststellen was anders ist (ausser die Reihenfolge der Tabellen)...

Das ist doch schon mal eine gute Nachricht.

[Spider IT]

Ich kann nur nochmal darauf hinweisen:

Code: Alles auswählen

[26-Feb-2013 09:53:52] /setup/dbupdate.php?step=10 MySQL error 1068: Multiple primary key defined
  ALTER TABLE con_upl_meta ADD PRIMARY KEY (id_uplmeta)

Es geht hier nicht um ein neues Feld, sondern um eins dass auf PRIMARY KEY umgestellt werden soll, das aber nicht kann, weil "Duplikate" vorhanden sind (mehrere gleiche Primärschlüssel sind nun mal nicht erlaubt).

Die fehlgeschlagene Aktion ist die, dass in der Tabelle con_upl_meta aus dem Feld id_uplmeta kein Primärschlüssel gemacht werden konnte, weil darin Duplikate (gleiche Einträge) gefunden wurden.
Such also nach doppelt oder mehrfach vorhandene Werte und korrigiere die, danach kannst du auch manuell das Feld auf PRIMARY KEY setzen.

Was das Update angeht, Änderungen an der Datenbank können nicht mehrfach gemacht werden.
Das Update läuft auch von eine 4.6er Installation aus, also sind auch alle dafür benötigten Änderungen enthalten, die beim Update von der 4.8.15 gar nicht mehr nötig sind.
Also werden die Änderungen entweder nur bei Bedarf aufgerufen, oder sie liefern eine Fehlermeldung zurück die dann ignoriert wird (die unsaubere Methode).
Eine nochmalige Ausführung des Updates ist also gefahrlos möglich (hab ich sogar schon - versehentlich - gemacht, als ich eine Migration machen wollte).
Außerdem kann man die DB sichern und notfalls wieder zurückspielen.

Bei der Migration werden keine Strukturänderungen an der DB durchgeführt.

Gruß
René

[xmurrix]

Ich kann nur nochmal darauf hinweisen:

Dennoch löst dies nicht das eigentliche Problem, wie kommt es dazu?

CONTENIDO prüft bei der Installation die Struktur der Tabellen in der Datenbank und vergleicht diese mit den Einträgen in der setup/data/tables.txt.

Code: Alles auswählen

[26-Feb-2013 09:53:52] /setup/dbupdate.php?step=10 MySQL error 1068: Multiple primary key defined
  ALTER TABLE con_upl_meta ADD PRIMARY KEY (id_uplmeta)

In der 4.6 er Reihe gab es keine Tabelle "con_upl_uplmeta", aber in der 4.8.

Wie kann es sein, dass das Setup nicht erkennt, dass die Tabelle con_upl_uplmeta kein Primary Key "id_uplmeta" hat und versucht hier ein Primary Key anzulegen?

Das Setup macht ja keine mehrfachen Änderungen an der Datenbank, es liest jeden einzelnen Eintrag setup/data/tables.txt und vergleicht das mit der vorhandenen DB Struktur. Nur, wenn das Feld/der Primary Key nicht gefunden wird, wird es hinzugefügt.

Die Fehlermeldungen sind auch nur für manche Tabellen, vermutlich basieren diese Tabellen auf eine andere Engine (ISAM??), so dass das Setup erst gar nicht die benötigten Infos auslesen kann und versucht, vorhandene Felder/Primary Keys anzulegen...