Après avoir réalisé des essais de la version 8.0.4 de Dolibarr en local, qui se sont révélés concluants, je viens de procéder à la migration manuelle de la V7.0.3 vers la V8.0.4, en production.
Lors de la migration des tables, j’ai obtenu le message suivant (répété plusieurs fois). … Warning: Division by zero in /home/clients/<mon_rep_client>/web/dolibarr/htdocs/core/class/stats.class.php on line 389 Warning: Division by zero in /home/clients/<mon_rep_client>/web/dolibarr/htdocs/core/class/stats.class.php on line 391
… j’ai poursuivi l’installation et tout semblait normal, sauf que lorsque l’on lance les ‘statistiques’ dans le module « adhérent » le message réapparaît.
dans ‘Outils d’administration’ => Infos Web Serveur, je constate également le message suivant : Warning: exec() has been disabled for security reasons in /home/clients/<mon_rep_client>/web/dolibarr/htdocs/admin/system/web.php on line 65
il semble que le fichier web.php ne se soit pas exécuté correctement et que l’identifiant ‘id’ du serveur (utilisateur/groupe n’ait pas été défini) car le paramètre : Serveur web utilisateur/groupe (real, ‹ id › command) ne comporte aucune valeur, alors qu’en local l’utilisateur/groupe est « www-data:www-data »
Comment remédier au problème ? En relançant l’installation ?
Dolibarr donne (configuration infomaniak)
apache ??? (rien concernant la version)
OS : debian 4.9.0.6
PHP 7.0
MariaDB 5.6.35
configuration locale lors des test :
apache 2.4.25/debian
OS : debian 4.9.0.8
PHP 7.0
MariaDB 5.5.5-10.1.37
J’ai procédé à une réinstallation, mais lors de la migration des bases le message d’erreur apparaît toujours:
D’après l’hébergeur ce n’est pas un problème de code Dolibarr ni de version de PHP, mais un problème de données dans la base (div/0)
Pourtant lors de l’installation en local, la migration de la base et les test sont tous OK !
je continue mes recherches, mais sans succès…
l’erreur est générée par le fichier htdocs/core/class/stats.class.php => function_getAllByYear
j’ai vérifié, les 2 fichiers sont strictement identiques en local sur ma base de test et sur le serveur infomaniak. le problème vient donc du calcul des données. Ce que je ne comprends pas c’est le pourquoi, puisque les bases sont strictement identiques. En effet, après avoir ré-installé une copie de la V8.0.4 de Dolibarr pour test sur le serveur ( avec toujours le même message d’erreur lors de la migration de la base, alors que localement tout se passe normalement) j’ai 'injecté la base de donnée locale qui est OK, dans la base de test sur le serveur, et malgré cela l’erreur persiste.
Tout se passe comme si le serveur n’interprétait pas la fonction function_getAllByYear de la même manière que localement.
lignes concernées 389 et 391
mes compétences en PHP sont trop limitées, quelqu’un peut m’aiguiller ?
A moins que le problème soit lié à la configuration du serveur: MariaDB notamment qui est dans une version supérieure…
config:
PHP 7.0.33 en local et PHP 7.0.32 sur le serveur
MariaDB 5.5.5-10.1.37 en local et MariaDB 5.6.35 sur le serveur
Bonjour,
$row->total et $row->avg doivent être nuls. Ce sont des résultats d’une requête SQL.
Active les log de Dolibarr depuis les modules.
Moi, j’y trouve cette requête :
2019-01-14 12:06:41 DEBUG 127.0.0.1 CommandeStats::_getAllByYear
2019-01-14 12:06:41 DEBUG 127.0.0.1 sql=SELECT date_format(c.date_commande,'%Y') as year, COUNT(*) as nb, SUM(c.total_ht) as total, AVG(total_ht) as avg FROM llx_commande as c WHERE c.fk_statut > 0 AND c.entity IN (1) GROUP BY year ORDER BY year DESC
@yves57
merci pour ta réponse et voici ce que donne dolibarr. log
sur le serveur:
AdherentStats::_getAllByYear
sql=SELECT date_format(p.dateadh,’%Y’) as year, count(*) as nb, sum(subscription) as total, avg(subscription) as avg FROM llx_subscription as p, llx_adherent as m WHERE m.statut != 0 AND p.fk_adherent = m.rowid AND m.entity IN (1) GROUP BY year ORDER BY year DESC
en localhost:
AdherentStats::_getAllByYear
sql=SELECT date_format(p.dateadh,’%Y’) as year, count(*) as nb, sum(subscription) as total, avg(subscription) as avg FROM llx_subscription as p, llx_adherent as m WHERE m.statut != 0 AND p.fk_adherent = m.rowid AND m.entity IN (1) GROUP BY year ORDER BY year DESC
je constate que m.statut !=0 et non >1 comme chez toi. Par contre je ne vois pas l’origine du problème, et notamment pourquoi l’interprétation des résultats est différente en local et sur le serveur, puisque à priori les bases (donc la valeur des champs) sont identiques et que les requêtes du fichier log sont strictement identiques…
@yves57
j’ai balayé toutes les cotisations, pour commencer. Effectivement, pour un adhérent le champ ‹ libellé de cotisation › ,n’était pas renseigné, mails il ne s’agit pas d’un champ date. De plus après correction, le problème persiste et qui plus est le même oubli sur la base locale ne provoque pas l’erreur…
@wdammak
module adhérent désactivé et réactivé sans effet.
merci pour la manip; tout c’est déroulé normalement et la base est Ok mais le warning au lancement des stats cotisations/adhérents demeure.
J’avais fait une sauvegarde de la base non compressée et téléchargé le fichier pour l’analyser, notamment ‹ llx_adherents › entre autres et je n’ai rien trouvé d’anormal dans les données…donc c’est toujours un mystère pour moi.
Je suis frileux pour modifier le code en production, sachant que le même code ne produit pas d’erreur en local. Je pense à un problème de configuration du serveur. J’attends une réponse de mon hébergeur sur ce point.
vous pouvez faire une copie du fichier à mettre à coté
de toute façon il y a rien de spécial, juste s’assurer que le nombre de la division n’est pas zéro
effectivement le message à disparu, Mais si je comprends le pourquoi (il ne peut plus y avoir de message concernant une div/0 puisque on ne prend en compte le résultat que si total et avg sont >0), comment se fait-il qu’avec le code original il n’y ai pas de ‹ warning › en local, lors de mes test. A moins, que le paramétrage en local fasse que mysql désactive les ‹ warnings ›, et que sur le serveur ce ne soit pas le cas.
De toute façon c’est un bug à signaler car le code n’est pas correct!
if($i>0 && $row->total)
$row->total peut être définie mais sa valeur est 0
if($i>0 && $row->total>0)
@wdammak
Tu as peut être raison, mais dans ce cas en local j’aurais dû avoir le même message. Comme c’est un ‹ message d’attention › (warning’) non bloquant et que je suis quasi certain que dans le paramétrage des bases mysql/mariadb ont doit pouvoir activer ou désactiver les ‹ warnings ›, ceci expliquerai celà.
c’est bien ça, confirmé par la réponse de mon hébergeur:
« Cher client…Par expérience cela proviendrait plutôt de la configuration de l’affichage des warnings effectivement. »
En rétablissant le fichier original /htdocs/core/class/stats.class.php et en modifiant le conf.php de dolibarr avec ton code cela désactive bien les messages d’erreur.