SQL-Error bei Datenbank-Update

[Andree]

wurde was am Importscript bezüglich des oben genannten Problems gemacht??

[fasse]

Nein, mir ist noch nicht ganz klar, was hier schief läuft.

Im Moment tippe ich darauf, dass euer DB-User zu wenig Rechte hat um bestehende Tabellen zu manipulieren.

Um hier eine Lösung zu finden, könnte man dies wie folgt mal versuchen:

Du spielst ein 1.4 Backup zurück, machst ein Update auf 2.0.x, welches dann auf einen Fehler läuft und würdest mir Zugang zu der DB gewähren, dann könnte ich schauen, wo er im Updatescript hängen geblieben ist und wir wüssten dann schon mal, an welchem Befehl es hapert.

[Andree]

Nein, mir ist noch nicht ganz klar, was hier schief läuft.

Im Moment tippe ich darauf, dass euer DB-User zu wenig Rechte hat um bestehende Tabellen zu manipulieren.

Um hier eine Lösung zu finden, könnte man dies wie folgt mal versuchen:

Du spielst ein 1.4 Backup zurück, machst ein Update auf 2.0.x, welches dann auf einen Fehler läuft und würdest mir Zugang zu der DB gewähren, dann könnte ich schauen, wo er im Updatescript hängen geblieben ist und wir wüssten dann schon mal, an welchem Befehl es hapert.

Können wir gerne machen!
Ich versuche das mal lokal zu Hause nachzustellen....

[Andree]

Können wir gerne machen!
Ich versuche das mal lokal zu Hause nachzustellen....

Hallo.

Habe mir zu Hause die Umgebung mal nachgebaut. Und siehe da - das Update läuft ohne Probleme! Habe jetzt auch die 2.0.2 hochgeladen und läuft bisher wunderbar!

[fasse]

Hi Andree,

zu Hause hast du wahrscheinlich auch alle Rechte in der Datenbank. Bei deinem Hoster werden dir bestimmte Rechte fehlen, so dass da das Update nicht richtig durchlaufen kann.

Gruß
Fasse

[handballer]

Ich hatte auch diesen Fehler. Leider konnte hier keine richtige Lösung gegeben werden. So habe ich mich durch try and error auf die Suche gemacht und festgestellt, daß das Update bei folgendem Statement hängenbleibt:

Code: Alles auswählen

alter table %PRAEFIX%_folders add constraint %PRAEFIX%_FK_FOL_ORG foreign key (fol_org_id)
      references %PRAEFIX%_organizations (org_id) on delete restrict on update restrict;

Das Problem liegt nicht in den Benutzerrechten, sondern an den zu diesem Zeitpunkt unterschiedlichen Kollationen. Die alte Tabelle %PRAEFIX%_organizations ist noch Latin, die neue %PRAEFIX%_folders schon in utf8. Nach Umstellung der Tabelle %PRAEFIX%_organizations auf utf8 funktioniert das Statement...

Gruß vom Handballer

[fasse]

Ui, jetzt wird es aber kompliziert.

Da wir die Kollationen beim Anlegen der Tabelle nicht angeben, nimmt er das Default aus der Datenbank. Wahrscheinlich hat der Hoster hier in der Zwischenzeit diese Default-Kollationen von Latin1 auf UTF8 umgestellt, so dass die neue Folders-Tabelle dann eine andere besitzt, wie die alte Organization-Tabelle.

Vielen Dank für den Hinweis, der könnte wahrscheinlich bei einigen Problemen in dieser Richtung die Ursache sein.

Viele Grüße
Fasse

[handballer]

So, um es noch komplizierter zu machen noch ein paar Nachträge. Entgegen meiner vorherigen Aussage liegt es nicht nur an der Kollation:

Ich benutze zur Zeit die Version 1.4.8 . Nun wollte ich auf die neue 2er updaten. In meiner Datenbank sind alle Tabellen im Typ MyISAM und mit der Kollation latin1_swedish_ci gespeichert. Beim Update kamen also diverse Fehlermeldungen. Durch folgende Änderungen lief das update dann doch durch:

• - In der Datenbank die Tabellen adm_organizations, adm_roles und adm_users auf den Typ InnoDB stellen.
  - Im Update file upd_2_0_0_db.sql die Zeile

  Code: Alles auswählen

  ALTER TABLE %PRAEFIX%_roles DROP FOREIGN KEY %PRAEFIX%_FK_ROL_ORG;

  löschen.

Ich werde nun noch die weiteren Tabellen auf den Typ InnoDB ändern um den zukünftigen Updates keine Steine in den Weg zu legen.

Dazu noch ein paar weitere Fragen:
Wann wurde der FOREIGN KEY %PRAEFIX%_FK_ROL_ORG integriert? Bei mir existiert dieser nicht was vermutlich den Fehler auslöst ...

Viele Grüße vom Handballer

[fasse]

Hallo Handballer,

kann es sein, dass dein Hoster vielleicht mittlerweile InnoDB zulässt ?

Dieser ForeignKey sollte schon seit Admidio 1.0 existieren. Hattest du aber am Anfang kein InnoDB zur Verfügung, wurde er natürlich nicht angelegt. Allerdings sollte dein Drop dann auch nicht auf einen Fehler laufen, da dies bei MyIsam generell der Fall ist und wir viele Leute haben, die MyIsam benutzen. So ganz kann dies noch nicht die Ursache sein.

Viele Grüße
Fasse