Hallo,

Die Version wird aber im Array $update['version'], welches bestimmt, welche Versionen als Ausgangspunkt des Updates dienen können, nicht aufgelistet.

Ja. Das wird die Ursache sein. Möglicherweise ist auch einfach vergessen worden, dass RC wieder zu entfernen. Wie dem auch sei. Von dort kommt man nicht mehr weg.

Die Prüfung erfolgt auf folgendes:

- Ist die Datei config/VERSION vorhanden?
- Ist die Zielversion laut config/VERSION größer als die Ausgangsversion?
- Ist die Ausgangsversion im Array $update['version'] enthalten, also behandelbar?

Was tatsächlich nicht geprüft wird, ist die Frage, ob die Zielversion durch das Skript abgedeckt ist.

Genau. Ein Nutzer soll die Datei VERSION hochladen, die im config-Verzeichnis zu finden ist. Lädt er nun die aktuelle Version herunter, wird er auch exakt die im Downloadverzeichnis befindliche VERSION nehmen und keine andere/modifizierte. Er wird, wie ich, in dieses Problem laufen. Problematisch ist, dass er das nicht bemerkt. Er hat dann, wie Du schon sagst, 2.4.20 (oder was auch immer) installiert, das Forum gibt sich aber als 2.4.99.1 aus. Noch läuft alles einwandfrei aber ein Update auf 2.4.99.2 wird schief gehen, da die Dateien und die Datenbank nicht auf dem notwendigen Stand (2.4.99.1) sind, die vorausgesetzt werden für das Update. Hier sollten wir in jedem Fall handeln.

Ich habe schon befürchtet, dass ich andere Stellen, die dieses Problem ebenfalls heraufbeschwören, übersehen haben könnte.

Ich will das heute (oder am Wochenende) noch auf einem anderen Server testen und werde berichten. Gegenwärtig ist es die einzige Problemstelle, ja.

Bitte beachte, dass die Änderung auf 128 Zeichen nicht durchgeführt wird, wenn man 2.4.99.1 irgendwie zum Laufen gebracht hat. Das sollte mMn. noch behoben werden.

Sprichst du über die Änderung der Tabelle für Tags?

Was ich meinte ist. Ich habe mein Forum bereits auf Version 2.4.99.1 geupdatet. Ich benötige also nur noch die Änderungen an der Datenbank, die in Version 2.4.99.2 hinzugekommen sind. Die Begrenzung der Felder auf 128 Zeichen würde ich nicht mitbekommen. Ich denke, die CHANGE-Statements müssten in beide if-Bedingungen. Sie werden dann im zweifel doppelt ausgeführt aber besser als gar nicht.

Ich möchte an dieser Stelle erneut anmerken, dass ich äußerst unzufrieden mit der gegenwärtigen Versionierung bin. Ich sehe nach wie vor keinen Vorteil oder Mehrwert aber durch x Dateien, RC, Sub- und Subsubversionen nur Probleme. Wir sollten hierüber ab Version 2.5 noch mal sprechen - finde ich.

Das habe ich noch nicht probiert, ich befürchte aber, dass der ALTER-Query dann abhängig von der SQL-Server-Konfiguration abgebrochen wird.

Das wäre unglücklich und auch eines der Probleme, die ich in unserem Updatescript ausgemacht habe. Wenn das Update schief geht an einer Stelle, dann hat man so eine Zwischenversion, von der man nicht mehr weg kommt. Selbst wenn man das SQL-Statement korrigiert im Script, lässt sich dieses nicht erneut aufrufen, da bereits ein Teil des Updates durchgeführt wurde. Wir benötigen hier ein Rollback oder etwas ähnliches. Ich in meiner Applikation mache es recht simple. Ich erzeuge für jeden SQL eine Subversion z.B. 20180106.0101 (Hauptversion ist das Datum hier 2018-01-06). Beim Update durchlaufe ich die diese Liste und prüfe, welche der Versionen größer ist als die bisherige und führe den SQL aus. Anschließend schreibe ich diese Subversion auch in die Datenbank. Sollte an einer Stelle ein SQL korrupt sein und das Update abbrechen, dann sehe ich, bei welchem SQL dies passiert ist und kann genau dort wieder einsteigen.

Dadurch, dass ich jedes SQL-Statement mit einer eigenen Version belege, muss ich auch nicht mehr zwischen Installation oder Update unterscheiden. Bei einer Installation durchläuft das Script einfach alle Einträge, beim Update nur die letzten/benötigten.

Das heißt dann wohl, dass mlf2_userdata.user_name die einzige weitere Spalte ist, die von dem Problem betroffen ist.

Wenn Du mich so festnagelst relativiere ich die Aussage: Das heißt also, dass mit user_name mindestens noch ein weiteres Feld existiert, dass Probleme macht.

Bleibt die Frage nach bereits eingetragenen Namen, die länger als 128 Zeichen sind und damit das Update verhindern.

Substr() könnten wir nutzen aber dann erzeugen wir u.U. Kollisionen. Der Name muss in jedem Fall nicht Unique sein, wie es aussieht. Aber auch hier stellt sich die Frage, wer hat schon einen Namen mit mehr als 50 Zeichen?

Mich hat das auch gewundert. Hat Taurec eventuell doch den Upload irgend eines Skripts vergessen?

Möglich. Er hat aber auch gesagt, dass es mit einer frischen Installation nicht ging. Das würde sich dann (fast) ausschließen, oder?

Alles weitere dann später
Micha