You are not logged in.
Bonjour,
lors de la MAJ GLPI de la version 9.1.2 vers 9.3.3 j'ai l'erreur suivante:
Mise à jour
Connexion à la base de données réussie
La version de la base de données semble correcte (10.1.26) - Parfait !
Mise à jour en 9.1.3
Traitement terminé. (1 seconde)
Mise à jour en 9.2
Traitement terminé. (8 secondes)
Api users tokens has been reset, if you use REST/XMLRPC api with personal token for authentication, please reset your user's token.
Mise à jour en 9.2.1
Changement de la structure de la base de données - glpi_tickets (8 secondes)
9.2.1 multiple alter in glpi_tickets - Erreur durant l'éxecution de la requête : ALTER TABLE `glpi_tickets` DROP INDEX `slas_id` , ADD INDEX `slts_ttr_id` (`slts_ttr_id`) , ADD `time_to_own` DATETIME DEFAULT NULL AFTER `time_to_resolve` , ADD INDEX `time_to_own` (`time_to_own`) , ADD INDEX `ola_waiting_duration` (`ola_waiting_duration`) , CHANGE `slts_ttr_id` `slas_ttr_id` INT(11) NOT NULL DEFAULT '0' - L'erreur est Key column 'slts_ttr_id' doesn't exist in table
Cependant, malgré cela je peux me connecter à GLPI, j'ai testé la création d'un ticket et cela fonctionne.
Y a-t-il un impact ailleurs ? Comment corriger cette erreur ?
D'avance, merci
Last edited by ledge01 (2019-05-06 15:46:22)
Offline
Je viens de m'apercevoir que je me suis trompé de catégorie, il devrait être dans : Installation GLPI sur Gnu/Linux
Un modérateur peut-il le déplacer ? ou dois-je en recréer un ?
Offline
je pense que votre migration précédente ne s'est déjà pas bien passée :
https://forum.glpi-project.org/viewtopic.php?id=155990
essayez de passer en mode debug et je pense que vous verrez plusieurs messages d'erreur. vous ne voyez pas de symptômes parce que vous n'utilisez pas les sla.
mais la migration n'est pas allée au bout il y a d'autres tables qui n'ont pas été migrées :
vérifiez les actions automatiques, les profils, les règles métier, paramétrage des notifications. est ce que tout fonctionne ?
Trouver la panne avant de réparer...
GLPI10.0.16 (ubuntu 22.04 PHP8.1 Mariadb10.6 ) plugins : comportements 2.7.3 reports 1.16.0 formcreator 2.13.9, datainjection 2.13.5 fields 1.21.9
Offline
Effectivement en lisant le lien je vois qu'il y avait un fichier à modifier pour la mise à jour vers le 9.1.1, il est probable que cela vienne de là.
Pour les notifications, profils, actions auto je ne vois pas de problèmes particulier.
Il serait peut-etre préférable de corriger cela, cependant comment procéder ?
Offline
Est-ce que quelqu'un a déjà été confronté à ce problème ?
Je suis un perdu, j'arrive à aller au bout de la mise à jour malgré les erreurs mais ce n'est pas très propre et cela pourrait poser des problèmes à l'avenir.
Offline
Vous pouvez modifier le fichier et relancer la migration
CentOS 6.5 - CentOS 7.x
PHP 5.6 - PHP 7.x - MySQL 5.6 - MariaDB 10.2 + APC + oOPcache
GLPI from 0.72 to dev version
Certifiée ITIL (ITV2F, ITILF, ITILOSA)
Offline
Bonjour,
le problème est que je suis déjà en 9.1.2, et ce depuis longtemps.
La migration peut-elle dnc être relancée malgré cela ? Si oui comment ?
Offline
Donc si vous êtes en 9.1.2 c'est que la migration vers la 9.3.3 ne c'est pas faite
CentOS 6.5 - CentOS 7.x
PHP 5.6 - PHP 7.x - MySQL 5.6 - MariaDB 10.2 + APC + oOPcache
GLPI from 0.72 to dev version
Certifiée ITIL (ITV2F, ITILF, ITILOSA)
Offline
après avoir fait une sauvegarde (en ligne de commande) et si vous êtes sur de savoir restaurer :
je vous propose de revenir en 9.1.2 de modifier la table glpi_tickets en renommant la colonne "slalevels_id" en "ttr_slalevels_id". puis lancer votre migration.
attention vous devez restaurer dle dump dans une base vide
Trouver la panne avant de réparer...
GLPI10.0.16 (ubuntu 22.04 PHP8.1 Mariadb10.6 ) plugins : comportements 2.7.3 reports 1.16.0 formcreator 2.13.9, datainjection 2.13.5 fields 1.21.9
Offline
Je pense que j'ai du mal m'exprimer.
Je travaille sur une machine virtuelle, donc je peux revenir en arrière avec des snapshots.
Même en ayant l'erreur lors de la migration de la version 9.1.2 vers la version 9.3.3 je peux continuer et ma migration se termine.
Sur la machine en version 9.1.2, la table glpi_tickets, la colonne "ttr_slalevels_id" porte déjà ce nom, je n'ai pas de colonne "slalevels_id"
De ce que j'ai pu comprendre, le problème de migration s'est passé lors de la version 9.1.1.
En faisant la migration 9.1.2 vers 9.3.3 j'ai les erreurs suivantes:
root@support:/usr/share/glpi/scripts# php cliupdate.php
Config::getCache() in /usr/share/glpi/inc/config.class.php line 2985
Service with name "Zend\Cache\Storage\Adapter\Apcu" could not be created. Reason: ext/apcu is disabled - see 'apc.enabled' and 'apc.enable_cli' Database version seems correct (10.1.37) - Perfect!
Current GLPI version : 9.1.2
New GLPI version : 9.3.3
Current GLPI database version: 9.1.2
New GLPI database version : 9.3.2
Default GLPI Language : fr_FR
========================================= Update to 9.1.3 ==========================================
Task completed. (0 seconds)
========================================== Update to 9.2 ===========================================
** Api users tokens has been reset, if you use REST/XMLRPC api with personal token for authentication, please reset your user's token.
Configuration values added for login_remember_time, login_remember_default, use_notifications, notifications_mailing, notifications_ajax, notifications_ajax_check_interval, notifications_ajax_sound, notificaTask completed. (5 seconds) ds)
========================================= Update to 9.2.1 ==========================================
DBmysql::query() in /usr/share/glpi/inc/dbmysql.class.php line 177
*** MySQL query error:
SQL: ALTER TABLE `glpi_tickets` DROP INDEX `slas_id` ,
ADD INDEX `slts_ttr_id` (`slts_ttr_id`) ,
ADD `time_to_own` DATETIME DEFAULT NULL AFTER `time_to_resolve` ,
ADD INDEX `time_to_own` (`time_to_own`) ,
ADD INDEX `ola_waiting_duration` (`ola_waiting_duration`) ,
CHANGE `slts_ttr_id` `slas_ttr_id` INT(11) NOT NULL DEFAULT '0'
Error: Key column 'slts_ttr_id' doesn't exist in table
Backtrace :
inc/dbmysql.class.php:206
inc/migration.class.php:657 DBmysql->queryOrDie()
install/update_92_921.php:237 Migration->migrationOneTable()
inc/update.class.php:406 update92to921()
scripts/cliupdate.php:160 Update->doUpdates()
PHP Fatal error: Uncaught RuntimeException: 9.2.1 multiple alter in glpi_tickets - Error during the database query: ALTER TABLE `glpi_tickets` DROP INDEX `slas_id` ,
ADD INDEX `slts_ttr_id` (`slts_ttr_id`) ,
ADD `time_to_own` DATETIME DEFAULT NULL AFTER `time_to_resolve` ,
ADD INDEX `time_to_own` (`time_to_own`) ,
ADD INDEX `ola_waiting_duration` (`ola_waiting_duration`) ,
CHANGE `slts_ttr_id` `slas_ttr_id` INT(11) NOT NULL DEFAULT '0' - Error is Key column 'slts_ttr_id' doesn't exist in table in /usr/share/glpi/inc/dbmysql.class.php:216
Stack trace:
#0 /usr/share/glpi/inc/migration.class.php(657): DBmysql->queryOrDie('ALTER TABLE `gl...', '9.2.1 multiple ...')
#1 /usr/share/glpi/install/update_92_921.php(237): Migration->migrationOneTable('glpi_tickets')
#2 /usr/share/glpi/inc/update.class.php(406): update92to921()
#3 /usr/share/glpi/scripts/cliupdate.php(160): Update->doUpdates('9.1.2')
#4 {main}
thrown in /usr/share/glpi/inc/dbmysql.class.php on line 216
Fatal error: Uncaught RuntimeException: 9.2.1 multiple alter in glpi_tickets - Error during the database query: ALTER TABLE `glpi_tickets` DROP INDEX `slas_id` ,
ADD INDEX `slts_ttr_id` (`slts_ttr_id`) ,
ADD `time_to_own` DATETIME DEFAULT NULL AFTER `time_to_resolve` ,
ADD INDEX `time_to_own` (`time_to_own`) ,
ADD INDEX `ola_waiting_duration` (`ola_waiting_duration`) ,
CHANGE `slts_ttr_id` `slas_ttr_id` INT(11) NOT NULL DEFAULT '0' - Error is Key column 'slts_ttr_id' doesn't exist in table in /usr/share/glpi/inc/dbmysql.class.php:216
Stack trace:
#0 /usr/share/glpi/inc/migration.class.php(657): DBmysql->queryOrDie('ALTER TABLE `gl...', '9.2.1 multiple ...')
#1 /usr/share/glpi/install/update_92_921.php(237): Migration->migrationOneTable('glpi_tickets')
#2 /usr/share/glpi/inc/update.class.php(406): update92to921()
#3 /usr/share/glpi/scripts/cliupdate.php(160): Update->doUpdates('9.1.2')
#4 {main}
thrown in /usr/share/glpi/inc/dbmysql.class.php on line 216
Malgré cela, lorsque je me connecte à GLPI après la migration je suis en 9.3.3
Offline
Vérifiez dans la table glpi_tickets que :
- vous n'avez plus le champ slas_id ni son index
- vous n'avez pas le champ slts_ttr_id et son index
- vous avez bien le champ slts_ttr_id et son index
Pour résumé, dans la migration slas_id est devenu slts_ttr_id puis slts_ttr_id
CentOS 6.5 - CentOS 7.x
PHP 5.6 - PHP 7.x - MySQL 5.6 - MariaDB 10.2 + APC + oOPcache
GLPI from 0.72 to dev version
Certifiée ITIL (ITV2F, ITILF, ITILOSA)
Offline
Bonjour,
Sur la machine en version 9.1.2
j'ai le champ slas_id:
| global_validation | int(11) | NO | MUL | 1 | |
| slas_id | int(11) | NO | MUL | 0 | |
| ttr_slalevels_id | int(11) | NO | MUL | 0 | |
J'ai également l'index: slas_id
| glpi_tickets | 1 | slas_id | 1 | slas_id | A | 1 | NULL | NULL | | BTREE | | |
Sur la machine en 9.3.3
J'ai le champ: slts_ttr_id
| slts_ttr_id | int(11) | NO | MUL | 0 | |
J'ai également l'index: slas_id pour la colonne slts_ttr_id
| glpi_tickets | 1 | slas_id | 1 | slts_ttr_id | A | 2 | NULL | NULL | | BTREE | | |
Offline
Bonjour,
j'ai pu me remettre sur mon problème de migration aujourd'hui et il semble résolu.
Etant donné que slas_id est devenu slts_ttr_id j'ai passé les commandes suivantes:
alter table glpi_tickets change slas_id slts_ttr_id int(11) not null default '0';
alter table glpi_tickets drop index slas_id
alter table glpi_tickets add index slts_ttr_id (slts_ttr_id);
la mise a jour s'est ensuite déroulée sans erreurs.
Merci de l'aide que vous m'avez apporté
Offline