You are not logged in.
Bonjour
Au moment de faire la mise à jour de la base de donnée, l'interface web de GLPI me note ce message :
Mise à jour
Connexion à la base de données réussie
Mise à jour -> 0.72.3
Traitement en cours...
0.72.3 reorder search.constant Erreur durant la mise à jour de la base de donnéesDuplicate entry '22-6-0' for key 2
Et ça reste bloqué là ....
Bug connu ? Solution ?
Merci de votre aide.
Offline
Personne n'a eu le problème ? Ce doit être un soucis du fichier téléchargé alors ...
Offline
Bonjour,
Je rencontre le même problème. J'essai de migrer de la v 0.72.21 vers 0.72.3 et rencontre le message :
0.72.3 reorder search.constant Erreur durant la mise à jour de la base de donnéesDuplicata du champ '22-6-0' pour la clef 'display'. J'ai la même erreur en testant la migration vers la version 0.72.4
J'ai testé suivant les deux méthodes : migration de la base existante, ou création de la base à vide puis restauration via le répertoire dump d'un fichier sauvegardé.
Mon environnement via EASYPHP 5.3.1.0 sous Win XP Pro :
PhP 5.3.2
APACHE 2.2.15
MySQL 5.1.45
PHPMYSQLADMIN 3.3.2
Je sais qu'il s'agit d'un environnement particulier, mais je m'en sert pour tester des plugins et les nouvelles versions GLPI avant d'impacter notre serveur de production sous Debian. Je n'avais jusqu'à présent pas rencontrer de difficulté.
Merci de votre aide éventuelle.
Offline
Humm généralement ces messages d'erreurs proviennent d'une base devenue inconsistante. C'est à dire d'une base qui a subi une mise à jour qui a échouée.
Il faut impérativement partir d'une base propre sur laquelle vous n'avez pas tentée de mise à jour (avec echec) auparavant avant de commencer une mise à jour.
JMD / Jean-Mathieu Doléans - Glpi-project.org - Association Indepnet
Apportez votre pierre au projet GLPI : Soutenir
Offline
Merci JMD pour ton aide. Mes différents essais se sont fait avec un export de ma base de production en format SQL. Cette base importée sur ma plateforme de text (EasyPhp) fonctionnait sans pb avec le version 0.72.21.
Existe-t-il une manip de réindexation de la base à effectuer avant la migration ?
Sinon le recours au backup XML serait-il plus pertinent ?
Merci de votre aide.
Offline
Pour partir d'une base 0.72 'propre', il faut supprimer toutes les tables de la base créée lors de l'install de la version 0.78 AVANT d'injecter votre dump.
Après vous lancez GLPI pour qu'il fasse la migration de la base.
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
Merci Yllen pour tes informations, mais peux tu me préciser ce que tu entends par "supprimer toutes les tables de la base". J'ai essayé de le faire via l'administration de ma base MySQL, en supprimant les tables, cela à crashé l'ensemble mais sans effet. Mes connaissances MySQL étant limité, j'ai sans doute mal interprété tes instructions.
Offline
Les tables de la 0.78 ne sont pas les mêmes que celles de la 0.72. Donc injecter un dump 0.72 est impossible.
Donc il faut supprimer les tables pour avoir une base vide et votre dump créera les tables en 0.72
Ensuite, GLPI vous proposera de migrer vos tables 0.72 en 0.78.
Souvent, les champ trouvés dupliqués correspondent à une relance de la procédure de migration.
La dernière solution, si votre base de départ n'est pas 'saine', est de corriger manuellement tous les problèmes avant 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
Merci pour ta réponse Yllen mais j'ai un doute sur le déroulement des opérations et surtout les manips à réaliser :
1°/ A partir de ma version 0.72 : "Supprimer les tables pour avoir une base vide" : où et comment ?
2°/ Installer une version vierge de la 0.78
3°/ Importer les données de ma 0.72 dans la 0.78 : comment si cela n'est pas possible par un dump de ma version 0.72 ?
4°/ Relancer la 0.78 qui va migrer les Tables 0.72 en 0.78.
Offline
Le 08-10-2010 à 11:35
Je suis sous DEBIAN
Problème de migration 0.72.21 vers 0.72.4 ..........
J'ai sauvegarde ma base glpidb de production (0.72.21)
mysqldump -u root -p glpidb > glpi.prod.08.10.2010.sql
J'ai téléchargé la dernière version stable de glpi (0.72.4)
cd /var/www
wget https://forge.indepnet.net/attachments/ … 2.4.tar.gz
Décompression de l'archive vers /var/www/temp
tar -xvzf glpi-0.72.4.tar.gz
Renommer le dossier glpi en glpi2 afin de conserver mon appli de production
mv glpi glpi2
cp -R glpi2/ /var/www/
Récupération de mes documents rattachés à GLPI et de mes dumps
cd /var/www/glpi/files
cp -R * /var/www/glpi2/files
Récupération de mes plugins
cd /var/www/glpi/plugins
cp -R * /var/www/glpi2/plugins
Création de ma base glpidb2
mysql -u root -p
show databases;
Une base glpidb existe déjà je ni touche pas (application de prod)
create database glpidb2;
Attribution des privilèges sur ma nouvelle base glpidb2
grant all privileges on glpidb2.* to glpidbuser@localhost identified by 'xxxxxxxxxxxx' ;
je sorts de la console MySQL
exit;
J'en profite pour vérifier l'état de ma base de production (optimisation également)
mysqlcheck -u root -p --auto-repair --check --optimize glpidb
tout est OK
Positionnement des droits sur l'appli glpi2
chown -R www-data /var/www/glpi2/
Accès à présent à l'interface http://localhost/glpi2
RAS choisir glpidb2 base crée au préalable
Se connecter à l'aide du compte administrateur glpi / glpi
RAS tout est OK
Installation et activation des plugins précédaient copier sur l'appli prod (0.72.21) vers /var/www/glpi2/plugins
Menu configuration plugins – installer – activer
RAS tout est OK les plugins sont activés
Migration de la base sauvegardée au préalable glpi.prod.08.10.2010.sql
mysql -u root -p glpidb2 < glpi.prod.08.10.2010.sql
ou depuis l'interface graphique GLPI
administration – restaurer
la restauration me renvoie vers le message suivant :
Traitement en cours...
0.72.3 reorder search.constant Erreur durant la mise à jour de la base de données duplicate entry '22-6-0' for key 2
Offline
Bonjour
Toujours pas de solution à proposer car pas de mise à jour possible pour moi depuis la 0.72.21 ....
Y a bien quelqu'un qui à ça dans un coin ...
Merci d'avance ...
Offline
Les solutions vous ont été données : duplicate entry cela veut dire que vous avez retenter plusieurs fois la migration.
Un conseil : partez de votre base 0.72 et installez la 0.78 (la procédure est désormais idempotente)
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
ok mais maintenant le problème, qui date de mars .., est que ma base est depuis longtemps dans cet état. Voyant ça en mars, je suis revenu à la version glpi 0.72.21 et j'ai continué à travailler avec ... Donc la base que je sauvegardes actuellement n'est plus saine depuis mars ;((((
N'y a-t-il un moyen pour résoudre cet état avant la mise à jour ?
Merci
Offline
Bon, ça ne va pas être simple, mais je vais essayer de vous aider.
Dans la table glpi_display, vous regardez si vous avez des type 22 avec des num 6 ou 5.
Si c'est le cas, vous les supprimer.
Ensuite, vous recherchez les type 22 avec un num à 9 => vous changez le 9 en 6
Ensuite, vous recherchez les type 22 avec un num à 8 => vous changez le 8 en 5
Le problème, c'est que la migration essaye de faire les 2 dernières actions indiquées mais cela fait des doublons.
Une fois cette opération faite, refaite une sauvegarde de votre base et essayez à nouveau une 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
Parfait ..!
Merci
Par contre j'ai le plugin datainjection qui apparemment n'existe pas pour cette version et avec la version 0.72, il me met un message d'erreur me parlant de version incompatible et plante le serveur web ...
Offline
Supprimez le plugin datainjection du répertoire plugin. En effet, seuls les plugins compatibles 0.78 doivent subsister , et datainjection n'est pas encore ré-écrit.
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
J'espère que ça va pas trop tarder car je l'utilise bcp ...
merci encore
Offline
Si vous voulez l'avoir plus vite, il faut :
- le modifier vous-même
- payer un prestataire pour le faire
Sinon, il faut être patient...
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