Fehler bei Update 4.8.15 - 4.8.18

[Spider IT]

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

Genau das passiert ja NICHT, das Feld soll lediglich im neuen PRIMARY KEY enthalten sein.
Da steht ja nicht "ADD id_uplmeta", sondern "ADD PRIMARY KEY (id_uplmeta)".

Gruß
René

[Faar]

Sieht für mich auch so aus, als ob lediglich ein Primary-Key erstellt werden soll, der meiner Meinung nach aber schon besteht.
Vielleicht hilft es hier, sich die Struktur der Tabelle mit phpmyadmin anzusehen, dort werden die bereits bestehenden Keys angezeigt.

[xmurrix]

...Genau das passiert ja NICHT, das Feld soll lediglich im neuen PRIMARY KEY enthalten sein.
Da steht ja nicht "ADD id_uplmeta", sondern "ADD PRIMARY KEY (id_uplmeta)"...

Gut, habe das Wort "Feld" gegen "Primary Key" geändert, so ist es richtig. Irgend eine Idee, was die Ursache für das Problem ist???

[Faar]

Ich habe in einer meiner Datenbanken das mal mit phpmyadmin durchgespielt:
Folgendes geht: ALTER TABLE `con_upl_meta` DROP PRIMARY KEY, ADD PRIMARY KEY(`id_uplmeta`).
Warum? Weil es nur einen Primary Key geben kann, also wird der vorherige zuerst gelöscht.

Die Angabe in Contenido tut das nicht und da kommt bei mir folgender Fehler:

Code: Alles auswählen

ALTER TABLE con_upl_meta ADD PRIMARY KEY (id_uplmeta)

ergibt: #1068 - Multiple primary key defined

[Spider IT]

Das ist die Fehlermeldung aus dem Anfangsposting, also ist genau das auch das Problem (und die Lösung gleich mit dazu)

Gruß
René

[xmurrix]

Das Setup liest einen Eintrag aus der CSV setup/data/tables.txt und ruft danach dbUpgradeTable() mit den Werten auf.

Ein Primary Key wird angelegt, wenn es in der Tabelle nicht vorhanden ist. Also klappt es, warum auch immer, mit der Erkennung nicht.

Man kann auch das Löschen eines vorhandenen Primary Key erzwingen, wenn man in der setup/data/tables.txt, die Einträgen mit Primary Key z. B. von

Code: Alles auswählen

"upl_meta";"id_uplmeta";"int(10)";"";"PRI";"";"";""

in

Code: Alles auswählen

"upl_meta";"id_uplmeta";"int(10)";"";"PRI";"";"";"1"

ändert, also am Ende den Wert "1" angeben. Dann wird beim Setup ein vorhandener Primary Key gelöscht, bevor es angelegt wird.

Die meisten Einträge in der "setup/data/tables.txt" mit "Primary Key" haben den Wert "1", manche sind leer "" und genau diese Einträge mit leerem String verursachen wohl die Fehlermeldungen bei sandra07.

Das löst sehr wahrscheinlich das Problem, aber wir haben immer noch nicht den Grund dafür, warum in der Funktion dbUpgradeTable() die Erkennung eines vorhandenen "Primary Key" fehlschlägt. Die Funktion dbUpgradeTable() ist auch schon einige Jahre alt, es braucht wohl eine Anpassung an neue Gegebenheiten...

Gruß
xmurrix

[Faar]

Eigentlich entsteht dadurch auch kein Fehler in der Datenbank, weil MySQL einfach nur die Erzeugung des Primary Key ablehnt.
Nur dann könnte es ungünstig sein, wenn zuvor ein anderes Feld als Primary Key eingerichtet war, denn dann würde nicht id_uplmeta als Primary Key eingerichtet werden.
Ich vermute, solche Bugs halten sich lange im System, weil es trotzdem läuft und der Fehler nur einmal bei der Installation auftritt.
Mit ALTER TABLE `con_upl_meta` DROP PRIMARY KEY, ADD PRIMARY KEY(`id_uplmeta`) wird das Problem grundsätzlich umgangen.
Oder entsteht ein neues dadurch, falls gar kein Primary Key zuvor bestand?

EDIT:
Es entsteht ein neues Problem falls gar kein Primary Key vorhanden war, denn dann kommt bei ALTER TABLE `con_upl_meta` DROP PRIMARY KEY, ADD PRIMARY KEY(`id_uplmeta`)

dieses: #1091 - Can't DROP 'PRIMARY'; check that column/key exists

Grüße,
Frank

[xmurrix]

...Mit ALTER TABLE `con_upl_meta` DROP PRIMARY KEY, ADD PRIMARY KEY(`id_uplmeta`) wird das Problem grundsätzlich umgangen...
...Oder entsteht ein neues dadurch, falls gar kein Primary Key zuvor bestand?...

Das Setzen des letzten Feldes eines Eintrags in der tables.txt auf "1" macht genau das, allerdings mit einer separaten SQL-Anweisung und auch nur, wenn vorher ein Primay Key gefunden werden konnte.

[Faar]

Da hat sich bei der Datenbank von version zu version etwas geändert und ich denke, dass manche Funktion versionsabhängig ist.
So wie die Fehlermeldung beim löschen des Primary Key, die in älteren Versionen als 5.1 angeblich nicht kommt.
Vielleicht funktioniert in neueren Versionen die Erkennung des Primary Keys nicht mehr zuverlässig.
...ich hab zum Beispiel irgendwo schon mal gesehen, dass manche den Programmablauf an einer Fehlermeldung der Datenbank fest machten.
Also so ähnlich wie: if( eregi ( 'error', mysql_error() ) )$sql='ALTER TABLE ...'
Soll absolut nicht unterstellen, dass hier so programmiert wurde aber irgendeine Änderung in mysql und schon geht vielleicht die Prüfung nicht mehr.