Serverumzug Ewige Rangliste - alte Saisons fehlen

Hallo zusammen,

ich habe mein Tippspiel auf einen neuen Plesk Server umgezogen, alles mit dem automatischen Migrationstool.
Soweit funktioniert auch alles bestens.

Lediglich fehlen die Daten der zurückliegenden Saisons in der ewigen Rangliste. Es wird so angezeigt, als wäre diese Saison die erste.
Die Datenbanken wurden sauber migriert und die Tabellen sind o.k.

Ich versteh das nicht. Irgendwie scheint das Script nicht korrekt zu rechnen.

Tippspiel ist in der aktuellsten Version inkl. Patches. PHP läuft unter 5.5.38 im FPM-Modus.

Viele Grüße
sOLUZion

Ja, Saison wird richtig gerechnet, passt alles. In der ewigen Rangliste auch wieder nur die Punkte aus 2016/2017.
Gleiches Spiel auch bei 2015/16. Es wird in der ewigen Rangliste immer nur die jeweils eingestellte Saison angezeigt.

Sieht so aus als würde das Skript die Daten der vorherigen Saisons nicht miteinlesen.

Die Abfrage die nicht korrekt ausgeführt wird ist im Ewigen-Ranglisten-Skript in Zeile 129. Ich hab die sql$ mal echoen lassen und gegen die DB im phpmyadmin getestet.

SELECT user_id, user_name, fav, SUM(tipps_2day) AS tipps, SUM(erg_2day) AS erg, SUM(dif_2day) AS dif, SUM(ten_2day) as ten, SUM(ext_2day) as ext, SUM(bon_2day) as bon, sum(pkt_2day) as pkt FROM bulitipp_saison_ranking WHERE precalc_id = '1' OR precalc_id = '118' OR precalc_id = '186' OR precalc_id = '460' OR precalc_id = '528' OR precalc_id = '596' GROUP BY user_id ORDER BY pkt DESC, erg DESC, dif DESC, ten DESC, ext DESC, bon DESC, tipps ASC

Wie es scheint ist die neuere MySQL-Version der Grund:

#1055 - Expression #2 of SELECT list is not in GROUP BY clause and contains nonaggregated column 'tsv_buli-17-18.bulitipp_saison_ranking.user_name' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by

Man müsste vermutlich im Skript die Anfrage anpassen, damit es wieder syntaktisch mit neueren MySQL-Versionen passt.

verhält sich leider komplett identisch.

im error.log genau gleich:
mysql_num_rows() expects parameter 1 to be resource, boolean given in /var/www/vhosts/tsvneuhausen.de/tippspiele.tsvneuhausen.de/bulitipp-17-18/content/ewige_rangliste.php on line 129

Die Version des aktuellen MySQL:

Ich werde morgen mal die sql-modes ausprobieren, das würde dann bei mir vermutlich funktionieren, aber jeder andere dessen Provider diese Anpassung nicht zulässt im shared-Umfeld fällt auf die Nase.
Insofern bin ich froh dass es nur dieses eine Skript ist, und die Daten ansonsten passen. Weil wir sind sind in der 10. BulitippSaison wovon einige von Anfang an dabei sind und die Wert auf die Ewige Rangliste legen.
Leider bin ich jetzt in Sachen SQL nicht der Held, aber ich werd mich morgen trotzdem mal ransetzen und das versuchen hinzubekommen ohne an der my.cnf zu biegen.

Nicht böse sein, aber es wird glaube ich echt Zeit für das neue bulitipp, weil der Code vom alten Bulitipp echt über den Zenith ist und mit Mainstream-Providern nicht mehr lange lauffähig sein wird.

So das Problem mit dem Group_by ab MySQL 5.7 konnte ich beheben. Der Fehler war weg, wenn man in die GROUP BY die Felder user_name und fav hinzugenommen hat, was aber dazu geführt hätte dass bei Usern die über die Jahre hinweg ihren Favoriten oder den Usernamen geändert haben jeweils nur noch einmal gelistet wurden mit nur einem Teil der Punkte, weil in der Abfrage mehrere Zeilen pro User gruppiert wurden in so einem Fall.

Will man aber systaktisch korrekt nur nach User_ID gruppieren, müssen ab Version Mysql 5.7 aus dem select der user_name und der fav raus. Dadurch würde aber in der Ewigen Rangliste bei Spielern die in der aktuellen Saison nicht mehr tippen kein Fav und der Username nicht gelistet. Zu diesem Zweck habe ich mir die aktuellen Userdaten aus der Usertabelle über einen Left Join rangeklebt.

So und jetzt funtionierts auch wie gewohnt ab MySQL 5.7.2 ohne an den Datenbankserver Einstellungen biegen zu müssen.
Wundert mich eigentlich, dass ich der erste mit dem Problem bin.

@Wilheml12: War nicht als Kritik gemeint. Sollte nur ein Hinweis sein dass derartige Anpassungen vermutlich in Zukunft zunehmen werden und dadurch zusätzlicher Aufwand ensteht mangels Alternative.