You are not logged in.
Ah mince c'est vrai le droit c'est pour les mises à jour de notes pas la lecture...
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
La 0.85 reprends les champs notepad d'un certains nombre d'objets et les mets dans une table à part. Donc si vous avez encore le champ dans la table des computers c'est que la mise à jour à bugguée.
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
Pouvez-vous également vérifier que dans la table glpi_computers vous n'avez plus le champ notepad ?
Si, il existe toujours.
Ça confirmerait la thèse du pb de migration.
Et comme la section ordinateur n'est pas la seule touchée, comme indiqué au début, la question vient d'évidence : puis-je relancer le processus de migration sur cette base ? Depuis le début ? à un certain point ? et comment ?
Offline
Pour voir à quelle niveau la migration aurait bugguée, avez-vous la table glpi_changes ?
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
La 0.85 est idempotente donc oui vous pouvez la relancer.
Pour cela il faut aller dans la table glpi_config et changer le numéro de version (changer 0.85.1 par 0.84.7) et reconnectez-vous sur glpi il vous proposera de faire 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
Pour voir à quelle niveau la migration aurait bugguée, avez-vous la table glpi_changes ?
pas de table glpi_changes
Offline
ok. Vous avez la table glpi_ticketcosts?
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'ai donc changé la version dans glpi_configs. La migration se lance, mais s'arrête sur une erreur sql :
update glpi_configs with backcreated - Erreur durant l'éxecution de la requête : INSERT INTO `glpi_configs` (`context`, `name`, `value`) VALUES ('core', 'backcreated', 0) - L'erreur est Duplicate entry 'core-backcreated' for key 'unicity
ok. Vous avez la table glpi_ticketcosts?
Oui, elle est vide.
Offline
Vous avez quelle valeur dans la table glpi_configs ?
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
Vous avez quelle valeur dans la table glpi_configs ?
quelle valeur de ?
Bon, j'ai viré le champ concerné par le insert qui provoquait l'erreur, de la table configs.
J'ai relancé la migration, cette fois aucune erreur, et elle est allée au bout.
Et maintenant, je peux ENFIN voir le détail des ordinateurs.
Donc problème réglé pour moi, mais il y a quand même quelque part un petit soucis dans la migration.
En tous cas, merci beaucoup pour ce debuging en live, et désolé d'avoir du secouer un peu le cocotier pour me sentir "écouté"
Offline
Mais on vous écoute mais lorsque l'on doit aider des dizaines de personnes bénévolement sur 3 versions différentes, ce n'est pas toujours évidement.
Et pour votre information, je suis développeuse du coeur de GLPI comme l'indique mon titre sur ce forum.
Heureuse que vous soyez dépanné.
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
Ou essaye de créer la table manquante :
CREATE TABLE `glpi_notepads` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`itemtype` varchar(100) COLLATE utf8_unicode_ci DEFAULT NULL,
`items_id` int(11) NOT NULL DEFAULT '0',
`date` datetime DEFAULT NULL,
`date_mod` datetime DEFAULT NULL,
`users_id` int(11) NOT NULL DEFAULT '0',
`users_id_lastupdater` int(11) NOT NULL DEFAULT '0',
`content` longtext COLLATE utf8_unicode_ci,
PRIMARY KEY (`id`),
KEY `item` (`itemtype`,`items_id`),
KEY `date_mod` (`date_mod`),
KEY `date` (`date`),
KEY `users_id_lastupdater` (`users_id_lastupdater`),
KEY `users_id` (`users_id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
Offline
ddurieux : non créer la table n'aurait pas suffit vu que la migration récupère tous les champs notepad des objets pour la remplir.
En relançant la migration sont problème est résolu.
Je clos ce post.
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
Ah oui exact, j'avais zappé ça
Offline