phpwcms Support Forum

Mein lieber Jensensen,

ich kann dir in diesem Fall wirklich nur zu 100% zustimmen und unterstütze die Bitte an Oliver, etwas mehr Hinweise auf erforderliche Massnahmen für die Updates zu geben.

Es wäre sicher auch möglich, schon bei der Rev. Nr. einen Anhang zu machen, der auf solche kleinen Gemeinheiten hinweist.

r405-db
könnte z.B. auf eine Änderung in der DB hinweisen und für jeden klar machen, dass ein richtiges UPDATE zu fahren ist und nicht nur die neuen Dateien über die alten zu bügeln sind!

r405-db-c
wäre zusätzlich eine Warnung, wenn auch in der config-Datei Neue Einträge oder Änderungen vorhanden sind, die einen Einfluss auf die Arbeitsweise des Programms haben können.

Ein Satz in Klartext (in Form einer Logdatei o.Ä.) wäre natürlich göttlich... das hatten wir mal!

Das wäre kein allzu grosser Aufwand für Oliver, aber wir paar übrig geblieben User hättten es um Welten einfacher, die neuen Versionen auf zu spielen und Fehler zu vermeiden.
Insbesondere, wenn man mit Subversion arbeitet hat man schnell mal einen neuen Dateisatz eingespielt, verpasst aber auch schnell mal wchtige Korrekturmassnahmen an DB oder Config...

Noch einmal in Kürze:
Bitte ein kleiner Hinweis bei solchen "gemeinen" Revisionen...
und wir könnten Nachfragen vermeiden und die Aufregung und der Ärger bei jedem Update bliebe in engen Grenzen

Gute Idee, hilft bloß jetzt nicht.
Bis r400 war alles restlos tacko - das Update auf r403 will jedoch einfach nicht funktionieren

…es ist eben ratsam auch wirklich alle "alten" steps erfolgreich absolviert zu haben.

Ich habe extra den automatischen Updater für DB ins Spiel gebracht. Ältere DB Updates könnte zum Beispiel die Community auf dieser Basis bauen. Mir fehlt Zeit, Zeit, Zeit. Und dieses Thema wäre genau das, was die Community komplett ohne mein Zutun realisieren kann. Findet Euch zusammen und schreibt das selbst.

Die Bezeichnung der Revisonen wird nicht geändert. Es ist eben sehr problematisch, zu garantieren, dass auch tatsächlich jeder den selben Datenbankstand hat, wenn er eben vorab schon mal was vergessen hat oder eben sehr alte Release immer wieder auffrischt.

Ich möchte mich jetzt aber auch nicht in Ankündigungen ergehen, was mir wie alles vorschwebt.

Sicher, das letzte Update war ein großer Schritt und auch etwas schnell erfolgt. Bei der Erstinstallation läuft es aber sauber durch.

DF6IH wrote:Claus: 4 Minuten und du kannst sagen welche Errors flogen ?!

Als ich das machte, gab es Alarm wegen doppelter wasweissich und ganz am Ende wieder immer noch

Fatal error: _setConfig failed in F:\xampp\htdocs\meinedomain\include\inc_lib\dbcon.inc.php on line 538

Oliver Georgi wrote:…es ist eben ratsam auch wirklich alle "alten" steps erfolgreich absolviert zu haben.

Habe ich alle gemacht - bis r400. Was gibt's noch zu tun außer die Files drüberzubügeln?

und dann haben wir mal $data an der Versagensstelle gedumpt und da war das so gut wie die komplette Seite.... das array wird doch drüber erst deklariert, wieso kommt der mit dem ganzen Krempel zurück ?

Hmmm.. ok auch nachvollzogen ... Möglicherweise ist das ganze zu voll ! Zu viele Daten ?!

//nochmal Edit: das TEXT Feld ist auf mediumtext geändert, also Platz genug gibt es, es wird aber nicht hineingeschrieben .

Claus, wir machen das mal auf einem Server, womöglich kapiert das Xampp sql die sql Felder nicht richtig, wenn es mediumtext wie text behandelt dann ist clausens Seite zu groß !

Wäre gut zuu wissen wie groß die Seiten jeweils sind auf denen das passiert ?!

ok
da sind ca. 1250 Seiten
und ca 7200 Content Parts
Der dump hatte ca 480.000 Zeichen
(wenn ich mich nicht verzählt habe )

In das Feld passen bei Mediumtext allerdings meiner Erinnernung nachca. 17 Millionen, sollte eigentlich genug Luft sein .... Wobei ich nicht sagen kann ob der dump vollständig war..... Wenn ich das richtig verstehe haben wir hier eine theoretische Begrenzung der Kapazität

Hast du mal den mySQLdumper versucht und die SQL-Datei in mehrere Dateien aufteilen lassen?

Nachdem ich gestern wie verrückt die DB upgedatet, mit Jürgen bis zum Erbrechen gedumpt und 3 Mal alle Dateien übergebügelt hatte, der Fehler aber blieb, ging ich nach Hause. Heute vormittag probierte ich dann nochmal, die Seite aufzurufen - was soll ich sagen: der Fehler war immer noch da. Vorhin probierte ich's dann nochmal und siehe da, nun funktionierte es. Meine schon vorhandene Neigung, an Magie zu glauben, erhielt fette Nahrung. Weiss der Geier....
4xmal die Dateien hin- und hergeschaufelt, alle Hinweise aus sowohl Forum als auch Wiki ausprobiert nutzten nichts: Abwarten hat's bewirkt. Wirklich? Wann kommt der nächste Kollaps?
Ich glaube, ich werde mal die DB diffen, wie von Oliver angeregt.

Vielleicht hat dein Virenscanner einfach jetzt erst die Dateien freigegeben.

Knut

Eben habe ich mich in's Backend eingeloggt - jetzt ist der Fehler wieder da! Was ist denn das? Ausgeloggt: alles paletti.
Wat ne K....
Da ist doch was oberfaul.

Gehst du von einem anderen Rechner im Netzwerk an den Xampp?
Laufzeit, zugewiesener Speicher, zuviel Last auf der Maschine?

Wenn ausgeloggt schreibt das System nicht in diese Tabelle, dass passiert m.W. nur im BE. -> http://forum.phpwcms.org/viewtopic.php?p=127466#p127466

Das BE war die ganze Zeit ok, auch nach dem update und ist es auch jetzt. Wenn ich mich aber einlogge (als admin), dann kommt besagter Fehler im Frontend (ausgeloggt ist der aber nicht da):
Fatal error: _setConfig failed in F:\xampp\htdocs\mydomain\include\inc_lib\dbcon.inc.php on line 538
Schaue ich mir das von einem anderen Rechner aus an (eingeloggt im ersten Rechner), dann ist der Fehler nicht da.

das deutet darauf hin, dass die Weichen für 99,6% gestellt sind.

Das DBSystem der 403 müsste doch nun eine Referenz für ein 100% Update sein, richtig ?

Das will sagen, dass es möglich sein müsste mit einem kleinen Script gegen eine bestehende Db zu checken wo was nicht ist, wie es sein soll. Das wär doch mal was, oder ?