[0.68.3] Pb avec restauration de dump MySql

Eric26 · 2007-05-10 11:32:45

Bonjour à tous.

J'ai remarqué un petit problème lors de la restauration d'une partie de ma base de données GLPI. Suite à une mauvaise manip, la table glpi_users s'est corrompu. Heureusement, je fais des dump réguliers de la totalité de la base et j'ai voulu restaurer seulement cette table.

J'ai alors édité le fichier de sauvegarde *.sql et j'ai isolé la partie de création et remplissage de la table glpi_users afin de l'injecter dans la base via phpmyadmin.

Toute la partie de structure de la table se passe bien (drop table if exist...) mais arrivé à INSERT INTO, j'ai une erreur MySql sur le champ "tracking_order".

En y regardant de plus près, j'ai remarqué que ce champ n'est rempli à "yes" ou "no" que pour les utilisateurs standards de GLPI (glpi, tech, post_only, etc...) mais pas pour les utilisateurs qui ont été créés après coup (valeur du champ = "", soit NULL ?). J'ai résolu le pb en ajoutant la valeur "no" à la place du champ dans le fichier sql avant de retenter un import. Et çà a fonctionné.

Je me demande tout de même à quoi peut servir ce champ dans la donnée n'apparait pas dans l'interface de gestion des utilisateurs de GLPI. En plus, çà met le bazar dans les dump de la base.

Bref, ce "tracking_order" a-t-il une quelconque importance ?

aurel · 2007-05-11 12:00:33

pour ce genre de question Eric26 va plutôt leur poser la question sur IRC c'est plus rapide et surtout plus pratique et je ne pense pas que se soit le bon endroit pour poser la question

A+

MoYo · 2007-05-11 12:11:05

non il n'a pas vraiment d'importance. C'est juste opur définir l'ordre d'affichage des tickets (date croissante ou decroissante)
mais normalement il devrait être rempli ce champ.. hum hum

Eric26 · 2007-05-11 12:58:41

Bonjour.

Je n'ai pas pu poser cette question sur l'IRC car, au boulot, ce protocole est bloqué. D'où ma question ici. Mais il n'y avait pas vraiment de caractère d'urgence puisque j'ai pu m'en sortir.

Je souhaitai simplement faire remonter un possible pb sur la sauvegarde et la restauration de la BDD de GLPI. J'ai refait des essais sur une base de test (nouvelle installation de GLPI sur un système autonome).

Résultat identique : Les utilisateurs "standards" ont le champ "tracking_order" référencé à "yes" ou "non" comme prévu. Par contre dès que l'on ajoute un utilisateur par l'interface d'administration de GLPI, ce champ est vide.

Donc, les sauvegardes réalisées reprennent ces caractéristiques. Une restauration partielle (édition des fichiers sql pour ne conserver que les données à restaurer) ou complète (via l'interface de l'administrateur) plante sur une erreur SQL. Normal, puisque ce champ ne peut pas être nul d'après ces caractéristiques en BDD.

Il doit y avoir comme un bug, non ? Je précise que la version de GLPI installée n'est pas issue d'une mise à jour d'une version précédente. J'ai installé deux plugins : Export Ical-Outlook et IP Adressing qui fonctionnent bien.

Forum GLPI-Project

Announcement

#1 2007-05-10 11:32:45

[0.68.3] Pb avec restauration de dump MySql

#2 2007-05-11 12:00:33

Re: [0.68.3] Pb avec restauration de dump MySql

#3 2007-05-11 12:11:05

Re: [0.68.3] Pb avec restauration de dump MySql

#4 2007-05-11 12:58:41

Re: [0.68.3] Pb avec restauration de dump MySql

Board footer