4294967295 Kommentare

Interessant ist ja die Korrelation zum heutigen Tag (und so hast du das wahrscheinlich auch bemerkt, nehme ich an.)

Wir müssen also auch mal sehen, ob die zwei nächsten Einträge am 26. und 27. Oktober desselben Jahres (beide mit 0 Kommentaren) eventuell am Stichtag ein ähnliches Verhalten zeigen (-warum auch immer-). Und das nur, wenn uns zwischenzeitlich nicht noch was ganz anderes einfällt.

Man Dankt! 🙄

Tja - eine Sternschnuppe - die nicht sein darf.

Also irgendwie kann ich mir nicht vorstellen dass es an irgendwelchen falschen Berechnungen oder so in der generellen Zusammenstellung zwischen DB Abfrage(n) und Template Ausgabe liegt, denn sonst müssten andere 0-Kommentar Einträge ja ein gleiches Verhalten zeigen. Ergo kann es nur die DB sein (oder ein Speicher/Plattenfehler) würde ich deswegen einfach mal behaupten. Letzteres ist unwahrscheinlich, da auf 2 unterschiedlichen Systemen. Wenn es also die DB ist kann es ja nur sein, dass entweder die Struktur falsch ist und irgendeine Eingabe etwas Falsches ausgelöst hat oder, dass tatsächlich der ID Integer sein Überlauf-Ende erreicht hat. Das müsste man doch checken können... Probiere mal mit PMA (das eigentlich 0 von nix bzw Leerer Datensatz o.s,Ä. zurückgeben müsste)

SELECT * FROM `styx_comments` WHERE entry_id = 1612

Dann einmal diese für die Summe aller Kommentare aller entries

SELECT COUNT(*) AS total FROM styx_comments c LEFT JOIN styx_entries e ON (e.id = c.entry_id) WHERE c.type = 'NORMAL' AND e.authorid = 1

und diese für die Felder des entries 'Sonntagsfahrt'; insbesondere das Value für das Feld 'comments'

SELECT * FROM `styx_entries` WHERE id = 1612

und speziell für die Sonntagsfahrt

SELECT COUNT(*) AS total FROM styx_comments c LEFT JOIN styx_entries e ON (e.id = c.entry_id) WHERE e.id = 1612

Die Frage des WARUM müsste man sich für später aufheben, denn ebenso unwahrscheinlich ist ( - finde ich - ), dass durch die "normale" SPAM Zugriffs-Schwemme jemals eine solch hohe Zahl erreicht würde (auch nicht in 13+ Jahren). Außer es findet/fand eine Art von Angriff statt, um einen solchen Überlauf zu erzwingen und damit irgendwelche Speicherfehler auszulösen. Selbst das ist schon sehr gewagt, denn das würde über 4 Mrd Zugriffe benötigen. Das hätte bei dem Provider von dem die Daten original stammen schon die Alarmglocken klingeln lassen... oder man müsste das irgendwie von Außen gezielt anspringen können...

Wenn durch die SQL queries wirklich etwas schlüssiges bzgl der Zahl bei rauskommt wäre ich echt verwundert.... außer, wenn die dritte query genau das dort ausgibt. Dann ist es wahrscheinlich müßig darüber zu spekulieren wie sie genau da hinein kam... Wahrscheinlich wäre es dann ein Fehler in deinen damaligen Übertragsbemühungen oder ein Folgefehler einer Übertrags Fehlermeldung, irgendwie als -1 oder so gewesen, das dort dann diese Zahl hineingezaubert hat. Die Lösung wäre also sehr einfach: Gehe mit PMA zum entry und überschriebe die Zahl mit 0.

Mach mal zusätzlich noch ein komplettes DB Backup (wenigstens von entries + comments). Danach kann man hinterher mal probieren einen Kommentar auf diesen Eintrag abzusetzen um zu sehen was dann passiert.

Nanana ganzes Universum... tztztz 😁 Kuipergürtel reicht...!

Wir sind uns gerade ins Gehege gekommen, denn ich hatte gerade den vorigen Kommentar noch etwas editiert. Siehe vorletzten Absatz.

Ich finde das gerade jene 3. Query ganz schnell Klarheit bringen würde. Gerade auch weil ja sonstige Statistik Ausgaben funktionieren. Und auch für die mögliche fixup Lösung. Denn das sollte man korrigieren weil ich nicht unbedingt weiß was passiert wenn man einen Kommentar dazugibt und das Faß zum Überlaufen bringt. (Wenn alles gut geht wäre es eine 1).