La table history ne se vide plus

Bonjour @Loic,

Je suis en version 4.0.40 de Jeedom.
Depuis environ le 10 janvier la table history (+27000 lignes en augmentation) ne se vide plus dans la table historyArch.
Le message d’erreur est:

Erreur sur history::archive() : [MySQL] Error code : 23000 (1062). Duplicate entry '4956-2020-01-01 00:00:00' for key 'unique' : INSERT INTO historyArch(cmd_id,`datetime`,value) SELECT cmd_id,`datetime`,avg(CAST(value AS DECIMAL(12,2))) as value FROM history WHERE `datetime` 

Il y a bien un doublon cmd-id, datetime:
image
image
La commande 4956 contient la conso annuelle de mon Linky pour l’année 2020.
Elle est mise à jour en permanence. C’est la valeur dans history qui doit être archivée.

Pourquoi la valeur contenue dans historyArch n’est-elle plus mise à jour comme avant ?

Les plugins sigri-linky et suivi-conso semblent être touchés par ce bug.

Bonjour,
Je ne saurait te répondre, on a effectivement changé le systeme d’archivage pour des questions de performance (l’ancien planté des box desfois la nuit). Pourquoi tu as un doublon je sais pas. En 4.1 j’ai remplacé le insert par un replace pour eviter le probleme et mis du try catch pour que si ca merde il passe quand meme sur les autres commandes.

Si c’est valide alors ca passera en v4 aussi

Merci pour la réponse rapide et pour le commit. :wink:

J’ai remplacé INSERT par REPLACE sans try/catch dans la fonction archive et ça a fonctionné pour moi.
La table history s’est bien vidée image et toutes les données sont maintenant dans historyArch image

Merci.

@jpty @Loic

j’ai ca aussi ce matin (j’utilise plugins sigri-linky)

2020-02-13 05:00:19 history Erreur sur history::archive() : [MySQL] Error code : 23000 (1062). Duplicate entry ‹ 636-2018-01-01 00:00:00 › for key ‹ PRIMARY › : INSERT INTO historyArch(cmd_id,datetime,value) SELECT cmd_id,datetime,avg(CAST(value AS DECIMAL(12,2))) as value FROM history WHERE datetime

Il est bizarre ton message d’erreur. Dans la structure de la table historyArch, je n’ai pas de PRIMARY:
image

Il existe une contrainte d’unicité sur le couple « cmd_id, datetime ». Donc on en conclue qu’une insertion a été effectuée sur la même commande pour une même date.

D’ou le replace qui devrait empecher ce genre de soucis

et en 4.0.40 non ?

Relis mon 1er message tout est dedans

Pardon effectivement la dernière ligne, je me suis emporté un peut vite …

Ce sujet a été automatiquement fermé après 24 heures suivant le dernier commentaire. Aucune réponse n’est permise dorénavant.