[Moses1]

Oh je - hört sich nicht gut an. Ist der Vorschlag "Step by Step" von Raphael 'ne Idee? Die Vorversionen wären ja verfügbar.

Meine Ausgangslage ist, dass ich Webauftritt incl Forum übernehmen werde, weil der bisherige langjährige Admin aufhören möchte. Und es wäre ja ein leichtes, einfach ein neues Forum zu starten - dann gehen aber viele Informationen verloren. Das Forum weiter unter 1.2.2 laufen zu lassen (auch möglich) halte ich für keine gute Idee, denn dann ist irgendwann mal ganz plötzlich wahrscheinlich Schluß, weil irgendwas klemmt.

Ist es angesichts der vielleicht sehr großen Schwierigkeiten intelligenter und effektiver, auf der Webseite zwei Foren (neues + altes) zu verlinken? Dann kann das alte noch so lange "genutzt" werden, bis es kracht, und gleichzeitig kann man mit dem neuen Forum einen Neustart machen - hat ja auch durchaus bereinigende Effekte.

Da ich das mangels Erfahrung nicht überblicken kann, wäre ich euch für Einschätzungen sehr dankbar.
Gruß
Martin

[Nik101010]

Die Erfahrung ist - man bekommt jedes Problem irgendwie gelöst. Die Frage ist, wie viel Zeit möchte man investieren. Aber nur weil's beim 1. Mal scheitert würde ich noch nicht aufgeben. 2 Foren parallel - wird nicht funktionieren, da müsstest du wenn das alte auf Read-only umstellen, oder es ähnliches unattraktiv machen, sonst wird sich kaum jemand im neuen Forum registrieren.

Step-by-step wäre eine Idee, wobei du auf die php Versionen verzichten können solltest.


Gruß

[StefanT]

Das Update arbeitet sowieso einen Versions-Sprung nach dem anderen ab, es sollte keinen Unterschied machen.

[Moses1]

Okay, dann war's das wohl mit dem Versuch, die olle Schaluppe auf modern zu frisieren ...
Danke, Gruß
Martin

[Nik101010]

Das Update arbeitet sowieso einen Versions-Sprung nach dem anderen ab, es sollte keinen Unterschied machen.

Es sollte

Aber ggf. kann man besser rausfinden zwischen welchen 2 Versionssprüngen der SQL Fehler auftritt. Offensichtlich kann ja die Usertable nicht korrekt verarbeitet werden...

[Moses1]

[/quote]
Es sollte

Aber ggf. kann man besser rausfinden zwischen welchen 2 Versionssprüngen der SQL Fehler auftritt. Offensichtlich kann ja die Usertable nicht korrekt verarbeitet werden...
[/quote]

Danke für diesen ermunternden Hinweis!

Ich denke mir nach dem ersten Frust und einer guten Mütze Schlaf inzwischen auch, dass ich es Step by Step einfach mal versuche.
Angesichts der Vielzahl von Einflußgrößen kann man ja kaum vorhersagen, ob es klappt oder nicht.

Natürlich kostet es Zeit, aber das Forum ist viele Jahre alt und hat eine fleißige Userschar. So haben sich viele Informationen angesammelt, die möglichst in einem laufenden Forum verfügbar bleiben sollten.

Noch eine Frage: Angesichts der Vielzahl von Vorversionen frage ich mich, über welche Versionsstufen ich gehen sollte - gibt es da eine Empfehlung?
Meine Idee war, jeweils in 1.4 und 1.6 über zwei Versionsupgrades zu gehen.

Und habe ich es richtig verstanden, dass ich wohl mit PHP 5.3 und MySQL 5.1 diesen Prozeß durchführen kann - oder muss ich da auch noch etwas "runter" gehen?

Gruß
Martin

[frostschutz]

Windows-Server *grusel*

Das fragliche Query in upgrade12.php (von 1.2.12-1.2.14)

PHP-Code:

// DST correction changes
        $db->update_query("users", array('dst' => 1), "dst=1");
        $db->update_query("users", array('dst' => 0), "dst=0");
        $db->write_query("ALTER TABLE ".TABLE_PREFIX."users CHANGE dst dst INT(1) NOT NULL default '0'"); 


Die update_query sehen irgendwie sinnlos aus (Setze dst auf 1 wenn dst gleich 1, und auf 0 wenn dst gleich 0).

Du könntest einfach mal ausprobieren was passiert wenn du vor dem Upgrade, das ALTER TABLE selber durchführst in phpMyAdmin. Wenn das Upgrade Script dann nochmal ein Alter Table macht schadet das nichts. Und die älteren Upgrade-Scripte scheinen sich auch nicht auf dst zu beziehen.

[StefanT]

Die update_query sehen irgendwie sinnlos aus (Setze dst auf 1 wenn dst gleich 1, und auf 0 wenn dst gleich 0).

Die Spalte hat vorher einen anderen Datentyp, irgendwas wird sich der Entwickler schon gedacht haben...

@Moses1: Ich habe da gerade eine Idee. Führe vor dem Upgrade (kannst du ruhig in einem Ruck probieren) dieses Query in der Datenbank aus:

Code:

UPDATE mybb_users SET dst=1 WHERE dst='yes'

[Moses1]

Vielen Dank für Eure Hinweise, das macht mir Hoffnung auf Erfolg

Windows-Server ist halt Teil meines beruflichen Umfeldes.
Und ich habe es bisher überlebt
Die Beschäftigung mit dem Forum und dem technischen Umfeld ist schon keine Sache für "mal eben". Da wollte ich nicht auch noch eine Baustelle "nicht-Windows- Server-betreiben" aufmachen.

Werde mich heute abend damit beschäftigen und gebe dann Nachricht.

[Moses1]

[/quote]
@Moses1: Ich habe da gerade eine Idee. Führe vor dem Upgrade (kannst du ruhig in einem Ruck probieren) dieses Query in der Datenbank aus:

Code:

UPDATE mybb_users SET dst=1 WHERE dst='yes'

[/quote]

Ergebnisse von heute Abend:
1. SQL-Dump
2. Obigen Vorschlag ausgeführt, macht er ohne Zicken (bei 303 Einträgen, es sind 885 User drin)
3. Forumsdatensicherung und neuen SQL Dump
4. Upgrade auf 1.6.9 durchgeführt, Fehlermeldung:
[25-Jan-2013 21:44:34] PHP Fatal error: <strong>[SQL] [1061] Duplicate key name 'longipaddress'</strong><br />ALTER TABLE mybb_posts ADD INDEX longipaddress (longipaddress) in C:\inetpub\wwwroot\forum\inc\db_mysql.php on line 550
5. Rücksetzen (auf Sicherungsstand unter Pkt. 3)
6. Upgrade auf 1.4.0 gestartet. Das startet ohne Admin-Abfrage und hängt sofort auf dem ersten Fenster. Es gibt aber keine Fehlermeldung im PHP-Log.
7. Rücksetzen wie unter 5.
8. Upgrade auf 1.4.9 gestartet, Fehlermeldung:
[25-Jan-2013 22:11:09] PHP Fatal error: <strong>[SQL] [1366] Incorrect integer value: '' for column 'longipaddress' at row 1</strong><br />
UPDATE mybb_posts
SET `longipaddress`='' WHERE pid = '3000'
in C:\inetpub\wwwroot\forum\inc\db_mysql.php on line 548

9. Schluß für heute, Posting hier
@ Frostschutz: Deinen Vorschlag werde ich dann morgen testen.

10: Hoffe, das es noch einen Tipp gibt