[2024-02-05 20:14:21][SCENARIO] [MySQL] Error code : 22001 (1406). Data too long for column ‹ logicalId › at row 1 : INSERT INTO message SET id = :id, date = :date, logicalId = :logicalId, plugin = :plugin, message = :message, action = :action, occurrences = :occurrences
L’erreur se produit et le message ne se lance pas quelque que soit le scénario utilisé.
Voici mon de test (on ne peut plus simple): Si je met « popup » à la place de message le popup fonctionne. C’est vraiment la fonction message qui génère l’erreur et qui ne s’execute pas.
logicalID ALTER TABLE cmd DROP INDEX logicalID; CREATE INDEX logicalID ON cmd (logicalId ASC);
Pourriez-vous me venir en aide afin de comprendre la source de cette erreur et rétablir le fonctionnement message dans les scénario ([MySQL] Error code : 22001 (1406)… voir plus haut) ?
Pour info j’ai refais un passage de 4.3.22 à 4.4.2 (à l’aide de VM) et résultat :
l’erreur vérification de base de données apparait suite à la mise à jour 4.4.2
par contre les messages fonctionne juste après la mise à jour.
J’ai donc deux souci qui sont peut-être lié ou pas
-1) Erreur vérification de base qui apparait suite à la mise a jour et dont j’ai des traces aussi dans les logs de mise a jour du Core.
Je ne comprends pas comment est constitué le [logicalId] qui apparait dans la table message pour un scénario.
Autant pour une commande, cette info existe nativement mais sauf erreur de ma part ça n’existe pas pour un scénario, à voir comment le core le crée et si ça à changé en 4.4
J’ai simplement renommer le scénario et la fonction message re-fonctionne!
Oui juste raccourcie le nom puis testé le message qui à fonctionné puis j’ai remis le nom d’avant et sa fonctionne toujours.
Quand j’ai relu le message d’erreur qui disait « Too long », j’ai pensé au nom de mon scénario (Garage : Interrupteur Double) puis j’ai fait la manip expliqué au dessus.
Incroyable quand même.
Par contre j’ai toujours l’affichage d’une erreur dans la vérification de la base de données :
(Je vais surement ouvrir un autre sujet dédié à cette erreur)
Et quand je supprime l’index et que je fais Réparer tous, l’index est bien re-créé mais j’ai toujours l’erreur d’affichée
D’ailleurs quand je fais une vérification générale j’ai des logs qui parle de cet Index.
[START CONSISTENCY]
[START CHECK AND FIX DB]
Fix : ALTER TABLE `cmd` DROP INDEX `logicalID`;
Fix :
CREATE INDEX `logicalID` ON `cmd` (`logicalId` ASC)[END CHECK AND FIX DB]
Check jeedom package...
OK
Check jeedom database...
Fix : ALTER TABLE `cmd` DROP INDEX `logicalID`;
Fix :
CREATE INDEX `logicalID` ON `cmd` (`logicalId` ASC)OK
Check crons...
Check filesystem right...
OK
Flush cache widget...
Check jeedom object...
OK
Check jeedom cmd...OK
Set cache hour...OK
Check composer...OK
Check nodejs...
Hit:1 http://security.debian.org/debian-security bullseye-security InRelease
Hit:2 http://deb.debian.org/debian bullseye InRelease
Get:3 http://deb.debian.org/debian bullseye-updates InRelease [44.1 kB]
Hit:4 https://deb.nodesource.com/node_18.x nodistro InRelease
Fetched 44.1 kB in 1s (31.1 kB/s)
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
apt-utils is already the newest version (2.2.4).
build-essential is already the newest version (12.9).
git is already the newest version (1:2.30.2-1+deb11u2).
lsb-release is already the newest version (11.1.0).
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
[Check Version NodeJS actuelle : v18.19.0 : [ OK ]
[Check Prefix : /usr and sudo prefix : /usr and www-data prefix : /usr : [ OK ]
OK
[END CONSISTENCY]
Bonjour,
Le soucis vient du calcul du champs logicalId qui donne quelques chose de trop long. Je ne sais pas trop pourquoi tu as ca, aucune raison que le champs soit trop long d’un coup (le calcul est toujours le meme) peut etre qu’avant la db laissait passer et plus maintenant.
Dans tous les cas j’ai poussé un truc en alpha ca devrait corriger le soucis.