You are not logged in.
Bonjour à tous,
je tourne en rond devant un problème de mise à jour de ma version 72.4 vers une version 80.5
apres avoir cherché nombre d'asctuces pour contouner mon problème, ma procédure bloque toujours sur le traitement de glpi_logs
si je le relance, j'enchaine sur une serie d'erreur sans jamais aboutir:
Error : glpi_tickets.assign does not exist.
....
j'ai entrepris de modifier les valeurs de mon php.ini (max_execution_time=0, memory_limit=-1)
d'importer la definitions des tables glpi_tickets* avant mon traitement
de purger glpi_history de la v72.4 avant maj
de ne migrer que vers une v78 avant de continuer...
sans succés
quelqu'un aurait une idée?
merci d'avances
Offline
Le problème est que le champ 'assign' existe depuis très très longtemps mais dans la table glpi_tracking.
Là, vous avez mélanger les champs d'une version avec les tables d'une autre.
Faire le test suivant : dans GLPI_configs, changer la valeur de la version pour remttre 0.72.4 et relancer la migration.
Mais avec toutes vos modifications, ce n'est pas du tout sur que cela fonctionnera.
En cas d'erreur, il faudra regarder les logs et les traiter une par une.
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
et bien ...
même en repartant d'une sauvegarde clean de ma v72.4 je rencontre le même pb et la version de glpi_configs reste en 72.4
cd qui m'interdit de tenter votre solution...
ou se trouve les logs qui peuvent m'orienter?
cordialement.
Offline
le problème est que votre 0.72.4 ne doit pas être clean.
Vérifiez sa structure avec le fichier install/mysql/glpi0.72.3-empty.sql
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 votre reponse, je m'y atèle!
Bon week-end
Offline
pas de meilleur resultat avec ce script si ce n'est d'avoir purger ma base...
je ne sais plus quoi faire si ce n'est que de rester en v72.4
Offline
Il ne fallait pas jouer ce script mais comme demandé vérifier la structure de votre base avec ce fichier.
Bon, repartez depuis la 0.72.4 et indiquez les messages au fur et à mesure. On va voir si on peut vous aider
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
alors, en partant de la 72.4, le script de mise à jour se bloque sur glpi_logs (2) (xseconde)
la page de l'explorateur se fige et s'est finit. plus d'activité
les messages erreurs
Error : glpi_tickets.assign does not exist.
....
et les suivants apparaissent si je recharge cette page en renvoyant les données
je pense qu'une partie des mises à jour s'est effectuée expliquant ces messages au second tour
...
Mise à jour
Connexion à la base de données réussie
Mise à jour -> 0.78
Redressement des données - glpi_tickets (7 Sec(s))
Error : glpi_tickets.assign does not exist.
Error : glpi_tickets.assign_group does not exist.
Error : glpi_tickets.assign_ent does not exist.
Error : glpi_users.auth_method does not exist.
Error : glpi_ticketfollowups.author does not exist.
Error : glpi_knowbaseitems.author does not exist.
Error : glpi_tickets.author does not exist.
Error : glpi_computers.auto_update does not exist.
Error : glpi_infocoms.budget does not exist.
Error : glpi_softwarelicenses.buy_version does not exist.
Error : glpi_tickets.category does not exist.
Error : glpi_softwares.category does not exist.
Error : glpi_knowbaseitems.categoryID does not exist.
Error : glpi_configs.category_on_software_delete does not exist.
Error : glpi_computers_softwareversions.cID does not exist.
Error : glpi_tickets.computer does not exist.
....etc....
J'effectuais cette fois une tentative vers la 0.78 ayant eu exactement les mêmes symptomes vers la v80.5
J'ai également pris le temps de comparer la structure des 141 tables de la v78 avec une instance vierge qui, elle, se migre trés bien...
c'est donc dans les données ou les liaisons que j'ai un problème. mais je ne sais pas trouver de logs pour avancer davantage...
merci de votre patience.
Offline
Bonjour,
Je trouve ça bizarre, j'ai lancé une migration de 0.71.5 => 0.80.3 et tout s'est super bien déroulé.
Est-ce que l'utilisateur qui se connecte à la base de données à bien tous les droits sur la base et les tables?
Avez-vous mis en place des triggers qui pourraient bloquer la migration?
Avez-vous essayé de renommer/supprimer les tables backup_* ?
Quelle version est indiquée dans glpi_configs.version?
Avant la migration, essayez d'exporter la structure de votre base de données (avec un client MySQL) puis comparez la avec celle indiquée dans le fichier install/mysql/glpi0.72.3-empty.sql. Ces fichiers sont-ils rigoureusement identiques?
Bon courage, @+
Offline
Là, il faut vraiment partir d'une 0.72.4 correcte.
Donc il faut impérativement vérifier si votre structure est conforme.
Vérifier surtout la table glpi_tracking (c'est elle qui semble poser problème)
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