Erreur dans la table history depuis passage en 4.0.40

[Francois]

Bonjour

depuis le passage en 4.0.40 (abvant en 4.0.38)

je constate que la tache history archive ed 5 h du mat se plante avec un duplicate key en SQL (voir log en dessous)

c est lier au plugin linkdin
apres quelque recherche

j ai constaté que le module history.class.php a été completement reecri dans cette version…

avant pour ecrire dans la table on avait des comandes SQL REPLACE maintenant c est des commandesSQL INSERT …

la récupération des linkdin est pas super et on recupère tous les jours toutes les valeurs d ou a mon avis le pb des duplicate …

C’est pas blocant pour le fonctionnement mais il n y a plus d historisation du coup …

quelqu un a t il eu le pb et avez vous une correction ou faut il rester en 4.0.38 en attendant

merci d avance

2020-02-13 05:00:06][ERROR] : Erreur sur history::archive() : [MySQL] Error code : 23000 (1062). Duplicate entry ‹ 3071-2018-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 <= :archiveTime				AND cmd_id=:cmd_id				AND value IS NOT NULL				GROUP BY UNIX_TIMESTAMP(datetime) DIV :archivePackage
[2020-02-14 05:00:06][ERROR] : Erreur sur history::archive() : [MySQL] Error code : 23000 (1062). Duplicate entry ‹ 3071-2018-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 <= :archiveTime				AND cmd_id=:cmd_id				AND value IS NOT NULL				GROUP BY UNIX_TIMESTAMP(datetime) DIV :archivePackage

[Jeandhom]

???

Problème d'archivage dans l'historique des données linky depuis V4.0.40

Bonjour à tous et à toutes depuis le passage en V4.40 … qui d apres le log a fait quelque modif sur les index de la base … j ai tous les soir lors de l archivage a 5h00 la nuit le message suivant : [Erreur] history::archive() : [MySQL] Error code : 23000 (1062). Duplicate entry ‹ 3071-2018-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 <= :archiveTime AND cmd…

[Francois]

@Jeandhom

???

Problème d'archivage dans l'historique des données linky depuis V4.0.40

je me suis rendu compte que c etait pas un pb du plugin mais du core d ou le message ici .
a fermer du coté plugin je pense du coup

[Jeandhom]

Il aurait été plus simple que tu changes la catégorie et le tag de l’autre sujet.
En plus, tout y est dit.

[Salvialf]

Je ne sais pas s’il faut en rire ou en pleurer :

Problème d'archivage dans l'historique des données linky depuis V4.0.40

Ce n’est que l’archivage des historiques qui plante. Le transfert history vers historyArch ne se fait pas. Il n’y a aucune perte de données.

[Francois]

désolé je maitrise pas parfaitement ce type de subtilité avec l outil …
au fait il y a une doc qq part j ai pas trouvé ?

[Jeandhom]

Tu as le stylo, tout en haut à droite de ton titre de sujet.

[Francois]

c est noté encore désolé j avais pas trouvé …

mais bon ca ne regle pas le pb de fond mais tu as raison faut essayer de garder de la cohérence dans les sujets …

[Salvialf]

Pour la dixième fois le « problème de fond » comme tu dis est corrigé en V4.1 et la correction sera poussée en V4 si OK:

La table history ne se vide plus

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

[Francois]

ok désolé mais c était pas super clair vu que c est exactement l inverse dans les fait le replace a ete remplacé par un insert en V4.0.40 … et pas l inverse
donc si je resume

corrigé en 4.1

marche jusqu en 4.0.38

plante en 4.0.40

j ai bon cette fois ? rire

donc resto en 4.0.38 et perte de toute les données entre 4.0.38 et 4.0.40 …vu qu on restaure a J - 3 ou 4

merci pour ton aide précieuse et désolé si ca te semblait évident cela ne l était pas pour moi a chacun sese capacité intelectuel désolé encore une fois

[Jeandhom]

Cela a été dit plusieurs fois. Si tu ne restaures pas en 4.0.38, tu n’auras pas de perte.
Tout reste dans la table history.

[Salvialf]

@jpty t’a pourtant bien expliqué que rien n’était perdu dans les historiques… Il t’a d’ailleurs expliqué toute la situation sur ton autre post je ne pense pas qu’il soit nécessaire d’en ajouter (ça fait 5h que ça dure quand même).

Si tu ne comprends pas bah fais confiance à ceux qui comprennent et prennent le temps de t’expliquer c’est plus sage non ?

[Francois]

ok j inciste pas

mais par quel miracle les donnée collectee entre lundi et vendredi vos etre dans la base si je restore la sauvegarde de lundi pour repasser en 4.0.38

je ne vois pas comment une sauvegarde faite avant que les données existent peut evité de les perdre
je vous rappel passage en 4.0.40 le 12 au soir je crois donc dans la sauvegarde les data du 12 …
nous sommes le 14 au soir donc je perd les data entre le 12 et le 14

je vais retrouver le Jeedom a la situation du 12 en V 4.0.38 et perdre les data depuis
c est pas dramatique mais bon faut juste le savoir

et j écoute toujours ce que vous dite mais je restore en 4.0.38 on va voir si j ai mes relevès de temperature de hier …on pari ?

[Jeandhom]

Là, je crois que l’on ne peut plus rien pour toi.

[Salvialf]

Donc c’est le passage des données de l’historique vers l’archivage de l’historique qui bug. Les données restent dans l’historique et ne sont pas archivées. Elles ne sont donc pas perdues. J’espère que tu ne me fais pas dire de bêtises mais c’est ce que j’en ai compris

On te dit d’arrêter de restaurer et tu parles encore de restauration… bref ne touche plus à rien et attend quelques jours c’est mon conseil mais tu fais bien ce que tu veux.

[Francois]

a ok …

trop tard mais vous me dite si je restaure en 4.0.38 je perds rien …excuser moi mais faut savoir …

Cela a été dit plusieurs fois. Si tu ne restaures pas en 4.0.38, tu n’auras pas de perte.
Tout reste dans la table history.

bon la j ai compris on reste en 4.0.40 on la le message mais ca impact rien puisque les données reste dans history et sont pas transferee dans historyARch …voila quand on m explique je comprend …merci pour votre aide

ok je touche a rien et j attends …

[Jeandhom]

@Francois

ok je touche a rien et j attends …

Voila.

[Francois]

merci désolé si j ai mis du temps a comprendre