Bonjour @BernardG25,
Avant tout, petit rappel sur ce qu'est le SQL mode ONLY_FULL_GROUP_BY et pourquoi il existe.
Contexte
Le plus gros avantage de MySQL par rapport à un autre SGBD, et ce pourquoi il est aussi répendu, c'est qu'il est permissif. Insérer une date "0"? Pas de problème. C'est un avantage parceque c'est le SGBD qui embête le moins de gens. Il permets beaucoup de choses. Le plus gros inconvénient de MySQL, c'est… qu'il est permissif =D OK il ne râle pas quand tu mets une date "0", mais ça n'a pas de sens.
Les SQL modes
Au fil des versions de MySQL, la décision a été prise par MySQL (Oracle) d'arrêter de supporter certains de ces comportements incohérents. Comme cette décision est "cassante" et risque donc d'embêter quelques personnes, MySQL a mis en place une solution temporaire de dernier recours pour supporter du code legacy: les SQL modes.
Par exemple, pour "faire passer" la date à "0" dont je parle plus haut, il faut activer le SQL mode "NO_ZERO_DATE", pour revenir au comportement des vieux MySQL sur ce sujet.
D'autres SQL modes sont… étonnants. Notamment le ERROR_FOR_DIVISION_BY_ZERO (une division par 0? pas de problème!) ou bien le… ONLY_FULL_GROUP_BY.
ONLY_FULL_GROUP_BY
Petit extrait de la doc à propos de ce SQL mode: "In this case, the server is free to choose any value from each group, so unless they are the same, the values chosen are nondeterministic, which is probably not what you want."
En d'autres termes, activer ONLY_FULL_GROUP_BY, c'est comme cocher l'option «permettre l'inconsistence et les réponses aléatoires». Cette incohérence est encore plus vraie depuis MySQL 5.7 "because GROUP BY processing has become more sophisticated".
Bref, oui, le SQL mode n'est pas permis sur ton instance, mais même si ça l'était, je te conseillerais personnellement de ne surtout pas l'utiliser.
Pour mon information, quel code te demande de mettre ce mode? Est-ce un développement spécifique? As-tu essayé de poursuivre l'installation sans exécuter cette requête?
Mikaël