Problème d'actualisation d'affichage de table dans phpmyadmin
Résolu/Fermé
stephdem
Messages postés
36
Date d'inscription
mardi 7 avril 2009
Statut
Membre
Dernière intervention
30 octobre 2019
-
10 févr. 2017 à 17:14
stephdem Messages postés 36 Date d'inscription mardi 7 avril 2009 Statut Membre Dernière intervention 30 octobre 2019 - 13 févr. 2017 à 14:56
stephdem Messages postés 36 Date d'inscription mardi 7 avril 2009 Statut Membre Dernière intervention 30 octobre 2019 - 13 févr. 2017 à 14:56
A voir également:
- Problème d'actualisation d'affichage de table dans phpmyadmin
- Table ascii - Guide
- Table des matières word - Guide
- Affichage double ecran - Guide
- Problème affichage fenêtre windows 10 - Guide
- Comment agrandir l'affichage de l'écran - Guide
4 réponses
yg_be
Messages postés
23427
Date d'inscription
lundi 9 juin 2008
Statut
Contributeur
Dernière intervention
14 janvier 2025
Ambassadeur
1 558
10 févr. 2017 à 18:40
10 févr. 2017 à 18:40
bonsoir, je vois une petite anomalie:
c'est bizarre, non, pourquoi 3056 lignes insérées?
je te suggère de faire l'essai avec une dizaine d'enregistrements, cela te permettra d'avoir une vue d'ensemble.
3056 lignes insérées. (Traitement en 0.2340 sec). Je fais… afficher Affichage des lignes 0 - 24 (total de 1528,
c'est bizarre, non, pourquoi 3056 lignes insérées?
je te suggère de faire l'essai avec une dizaine d'enregistrements, cela te permettra d'avoir une vue d'ensemble.
stephdem
Messages postés
36
Date d'inscription
mardi 7 avril 2009
Statut
Membre
Dernière intervention
30 octobre 2019
10 févr. 2017 à 19:09
10 févr. 2017 à 19:09
Bonjour,
Oui, c’est anormal ce 3056, soit 2 fois 1528… mais quand je regarde la table j’ai bien 1528 lignes de données et pas plus (avec les anciennes données).
Si je commence par Truncate j’ai d’emblée 1528 lignes de données.
Maintenant merci du pilotage.
J’ai supprimé les 1516 dernières lignes de mon fichier csv, sauvegardé (donc 12 lignes restantes, en plus de la ligne avec les noms de champs).
J’ai fait truncate et recommencé le LOAD DATA LOCAL INFILE.
Je lis : 12 lignes insérées. (Traitement en 0.0312 sec)
Alors j’ai 12 lignes de données… mais les erreurs n’ont pas été corrigées (c’est la version ancienne que je vois à l’écran… sur 12 lignes, et pas plus !).
Il n'y a qu'un seul fichier csv avec ce nom dans ce dossier, donc pas de risque de mauvais aiguillage.
Casse-tête !
J’attend de tes nouvelles.
Steph
Oui, c’est anormal ce 3056, soit 2 fois 1528… mais quand je regarde la table j’ai bien 1528 lignes de données et pas plus (avec les anciennes données).
Si je commence par Truncate j’ai d’emblée 1528 lignes de données.
Maintenant merci du pilotage.
J’ai supprimé les 1516 dernières lignes de mon fichier csv, sauvegardé (donc 12 lignes restantes, en plus de la ligne avec les noms de champs).
J’ai fait truncate et recommencé le LOAD DATA LOCAL INFILE.
Je lis : 12 lignes insérées. (Traitement en 0.0312 sec)
Alors j’ai 12 lignes de données… mais les erreurs n’ont pas été corrigées (c’est la version ancienne que je vois à l’écran… sur 12 lignes, et pas plus !).
Il n'y a qu'un seul fichier csv avec ce nom dans ce dossier, donc pas de risque de mauvais aiguillage.
Casse-tête !
J’attend de tes nouvelles.
Steph
yg_be
Messages postés
23427
Date d'inscription
lundi 9 juin 2008
Statut
Contributeur
Dernière intervention
14 janvier 2025
Ambassadeur
1 558
10 févr. 2017 à 20:18
10 févr. 2017 à 20:18
je suis perplexe:
- tu fais truncate
- tu vérifies que la table est vide
- tu fais load à partir d'un fichier csv que tu viens de modifier (réduisant son contenu de 1528 à 12 lignes)
- ta table contiens 12 enregistrements, mais le contenu de ces enregistrements est différent du contenu du fichier csv, mysql ayant apparemment mémorisé l'ancien contenu des enregistrements correspondants
c'est bien cela?
es-tu certain que phpmyadmin affiche exclusivement le contenu de la table, sans jointure avec une autre table?
- tu fais truncate
- tu vérifies que la table est vide
- tu fais load à partir d'un fichier csv que tu viens de modifier (réduisant son contenu de 1528 à 12 lignes)
- ta table contiens 12 enregistrements, mais le contenu de ces enregistrements est différent du contenu du fichier csv, mysql ayant apparemment mémorisé l'ancien contenu des enregistrements correspondants
c'est bien cela?
es-tu certain que phpmyadmin affiche exclusivement le contenu de la table, sans jointure avec une autre table?
stephdem
Messages postés
36
Date d'inscription
mardi 7 avril 2009
Statut
Membre
Dernière intervention
30 octobre 2019
13 févr. 2017 à 14:56
13 févr. 2017 à 14:56
Bonjour,
C’est 100% exact !
Merci de l’éclairage, cela m’a aidé à trouver.
Je suis rassurée car ce n’était pas une boulette de ma part.
Donc après la réduction à 12 lignes de données, j’ai testé en changeant manuellement une donnée.
Et la modif a été bien intégrée.
C’était du texte changé sur du texte ce qui m’a mis la puce à l’oreille.
Toutes les données que j’avais corrigées étaient des nombres relatifs.
Ils avaient bien été intégrés une première fois, mais pas pour les valeurs de corrections.
Les champs concernés étaient classés par moi decimal 2,1.
J’ai changé en Varchar(4) et tout est rentré dans l’ordre.
Je n’ai pas compris pourquoi decimal 2,1 créait le blocage après avoir marché, mais enfin j’avance.
Merci yg_be!
Je marque résolu
Steph
C’est 100% exact !
Merci de l’éclairage, cela m’a aidé à trouver.
Je suis rassurée car ce n’était pas une boulette de ma part.
Donc après la réduction à 12 lignes de données, j’ai testé en changeant manuellement une donnée.
Et la modif a été bien intégrée.
C’était du texte changé sur du texte ce qui m’a mis la puce à l’oreille.
Toutes les données que j’avais corrigées étaient des nombres relatifs.
Ils avaient bien été intégrés une première fois, mais pas pour les valeurs de corrections.
Les champs concernés étaient classés par moi decimal 2,1.
J’ai changé en Varchar(4) et tout est rentré dans l’ordre.
Je n’ai pas compris pourquoi decimal 2,1 créait le blocage après avoir marché, mais enfin j’avance.
Merci yg_be!
Je marque résolu
Steph