Erreur dans la table history depuis passage en 4.0.40

Tags: #<Tag:0x00007f5935480c48>

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

???

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

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

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

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é ?

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

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 …

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:

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

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.

2 J'aimes

@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 ?

2 J'aimes

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 ?

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

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.

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 …

Voila. :sunglasses:

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

3 J'aimes

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