Problemes mySQL...
Résolu
ZeMaxou
Messages postés
3
Date d'inscription
Statut
Membre
Dernière intervention
-
ZeMaxou Messages postés 3 Date d'inscription Statut Membre Dernière intervention -
ZeMaxou Messages postés 3 Date d'inscription Statut Membre Dernière intervention -
Bonjour,
Bon je vais commencer par le début.
J'avais au début de la semaine 3 forums:
- Un de type phpBB
- Un de type Invision Power Board
- Un de "fabrication maison"
J'ai donc entrepris de les mettre sur un seul et meme forum et je souhaitais que cela soit un PunBB.
Quelques requetes pour créer les nouvelles tables, puis export sur la nouvelle base de données... j'ai incrémenté les ids des users et des posts du second forum pour qu'ils soient superieurs a ceux du premier (j'ai bien sur j'ai bien sur refait la meme chose sur toutes les tables ou on trouve ces ids) puis quelques requetes pour mettre a jour les nombres de messages un peu partout... Apres une journée la tete dans mysql tout semble fonctionner correctement.
A une petite exception pres.
Les messages invités apparaissent des fois en double, en triple ou en quadruple, ce qui est tres gênant puisque le "décallage" occasionné empeche l'acces aux réponses les plus récentes.
Ce qui est le plus bizarre, c'est que le phénomène n'est pas systematique et qu'il n'arrive qu'environs un quart du temps. Pendant 2 heures, tout va fonctionner et ensuite pendant une demi heure le nombre d'exemplaire de ces posts va varier entre 2 et 4.
J'ai donc utilisé le mode deboguage de PunBB pour identifier la requete avec laquelle il y a un soucis et il s'agit de celle ci:
Cette requete est un peu complexe pour mon niveau et je ne comprends pas exactement ce qu'elle fait mais ce qui est sur c'est que lorsque je l'execute directement sur le serveur mySQL j'ai le meme phénomene d'aléatoirité des resultats (alors que le forum est fermé et qu'aucune modification sur la base n'est effectuée entre les differents essais de la requete)...
J'ai bien entendu vérifié a plusieures reprises qu'il n'y avait pas de posts qui auraient été importés en double.
Personne n'a pu m'aider sur le forum de PunBB et visiblement je n'ai pas fait d'erreur dans la base de données...
Voici, pour ceux qui les voudraient les caracteristiques de ma BDD et du forum PunBB que j'ai d'installé:
Toutefois je pense serieusement à un probleme de mySQL, on m'a suggeré que des différences de jeu de caracteres dans les tables importées pouvaient etre à l'origine du probleme, pourtant les caracteres sont affichés correctement...
Quelle est selon vous la meilleure solution pour moi?
Je vous remercie d'avance pour vos réponses :)
Bon je vais commencer par le début.
J'avais au début de la semaine 3 forums:
- Un de type phpBB
- Un de type Invision Power Board
- Un de "fabrication maison"
J'ai donc entrepris de les mettre sur un seul et meme forum et je souhaitais que cela soit un PunBB.
Quelques requetes pour créer les nouvelles tables, puis export sur la nouvelle base de données... j'ai incrémenté les ids des users et des posts du second forum pour qu'ils soient superieurs a ceux du premier (j'ai bien sur j'ai bien sur refait la meme chose sur toutes les tables ou on trouve ces ids) puis quelques requetes pour mettre a jour les nombres de messages un peu partout... Apres une journée la tete dans mysql tout semble fonctionner correctement.
A une petite exception pres.
Les messages invités apparaissent des fois en double, en triple ou en quadruple, ce qui est tres gênant puisque le "décallage" occasionné empeche l'acces aux réponses les plus récentes.
Ce qui est le plus bizarre, c'est que le phénomène n'est pas systematique et qu'il n'arrive qu'environs un quart du temps. Pendant 2 heures, tout va fonctionner et ensuite pendant une demi heure le nombre d'exemplaire de ces posts va varier entre 2 et 4.
J'ai donc utilisé le mode deboguage de PunBB pour identifier la requete avec laquelle il y a un soucis et il s'agit de celle ci:
SELECT u.email, u.title, u.url, u.location, u.use_avatar, u.signature, u.email_setting, u.num_posts, u.registered, u.admin_note, p.id, p.poster AS username, p.poster_id, p.poster_ip, p.poster_email, p.message, p.hide_smilies, p.posted, p.edited, p.edited_by, g.g_id, g.g_user_title, g.g_color, o.user_id AS is_online FROM posts AS p LEFT JOIN users AS u ON u.id=p.poster_id INNER JOIN groups AS g ON g.g_id=u.group_id LEFT JOIN online AS o ON (o.user_id=u.id AND o.idle=0) WHERE p.topic_id=472 ORDER BY p.id LIMIT 0,25
Cette requete est un peu complexe pour mon niveau et je ne comprends pas exactement ce qu'elle fait mais ce qui est sur c'est que lorsque je l'execute directement sur le serveur mySQL j'ai le meme phénomene d'aléatoirité des resultats (alors que le forum est fermé et qu'aucune modification sur la base n'est effectuée entre les differents essais de la requete)...
J'ai bien entendu vérifié a plusieures reprises qu'il n'y avait pas de posts qui auraient été importés en double.
Personne n'a pu m'aider sur le forum de PunBB et visiblement je n'ai pas fait d'erreur dans la base de données...
Voici, pour ceux qui les voudraient les caracteristiques de ma BDD et du forum PunBB que j'ai d'installé:
Base de données: MySQL 5.0.32-Debian_7etch1-log Lignes : 332373 Taille : 15.7 MB Avant de proceder a l'importation des données j'ai installé les mods suivants: -Colored_Usergroups-1.0.2 -PBB SpellChecker 1.01 -Smilies manager 1.3.1 -PunToolBar 1.5
Toutefois je pense serieusement à un probleme de mySQL, on m'a suggeré que des différences de jeu de caracteres dans les tables importées pouvaient etre à l'origine du probleme, pourtant les caracteres sont affichés correctement...
Quelle est selon vous la meilleure solution pour moi?
Je vous remercie d'avance pour vos réponses :)
A voir également:
- Problemes mySQL...
- Mysql community server - Télécharger - Bases de données
- Could not connect to mysql! please check your database settings! - Forum Redhat
- Mysql error 1 ✓ - Forum Réseaux sociaux
- Phpmyadmin a tenté de se connecter au serveur mysql, et le serveur a rejeté la connexion. merci de vérifier les valeurs de host, username et password dans la configuration et de s'assurer qu'elles correspondent aux informations fournies par l'administrateur du serveur mysql. ✓ - Forum PHP
- Access vs mysql - Forum Webmastering
6 réponses
salut,
effectivement c'est complexe…
comme c'est un problème de doublons, as-tu essayer avec 'DISTINCT'.
c'est peut être un peu bourrin mais bon, c'est une piste !
-;o)
et avec des parenthèses pour identifier les clauses ça simplifierait peut être la requête pour le serveur.
en tout cas, bon courage !!!
effectivement c'est complexe…
comme c'est un problème de doublons, as-tu essayer avec 'DISTINCT'.
c'est peut être un peu bourrin mais bon, c'est une piste !
-;o)
et avec des parenthèses pour identifier les clauses ça simplifierait peut être la requête pour le serveur.
en tout cas, bon courage !!!
Bonjour,
Il faudrait vérifier que ta table posts ne contienne pas de doublons...
Exécute cette requête pour voir :
SELECT
poster,
posted, -- C'est bien la date ? (1)
count(*) AS nombre,
'SELECT id FROM posts WHERE poster="' + poster + "' AND posted = "' + posted + '"' AS requete
FROM posts
WHERE
poster_id IS NULL -- Puisque le problème ne concerne que les posteurs non enregistrés (2)
AND nombre > 1
GROUP BY poster, posted
Si je ne me plante pas, cette requête te sortira tous les doublons (nom, date, et nombre de doublons), et la requête qui te permettra de leur mettre la main dessus. Il te restera à les éliminer de la base de données à la main... (Je ne suis pas sûr de la concaténation en mysql, j'ai mis des « + » mais il faut peut-être autre chose...)
Dalida, je ne pense pas qu'un DISTINCT y change quoi que ce soit, puisque les doublons ne poussent surement pas le vice jusqu'à avoir le même p.id (ce serait grave !)
Xavier
(1) Ce que j'ai cherché à afficher, c'est la date du post. Si ce n'est pas le champ "posted", alors il faut le remplacer par celui qui va bien, y compris dans la clause GROUP BY.
(2) Je ne sais pas comment fonctionne punBB. J'ai fait comme si un utilisateur non enregistré était représenté par un posts.poster sans post.poster_id, mais si ce n'est pas le cas, il faudra adapter cette ligne
Il faudrait vérifier que ta table posts ne contienne pas de doublons...
Exécute cette requête pour voir :
SELECT
poster,
posted, -- C'est bien la date ? (1)
count(*) AS nombre,
'SELECT id FROM posts WHERE poster="' + poster + "' AND posted = "' + posted + '"' AS requete
FROM posts
WHERE
poster_id IS NULL -- Puisque le problème ne concerne que les posteurs non enregistrés (2)
AND nombre > 1
GROUP BY poster, posted
Si je ne me plante pas, cette requête te sortira tous les doublons (nom, date, et nombre de doublons), et la requête qui te permettra de leur mettre la main dessus. Il te restera à les éliminer de la base de données à la main... (Je ne suis pas sûr de la concaténation en mysql, j'ai mis des « + » mais il faut peut-être autre chose...)
Dalida, je ne pense pas qu'un DISTINCT y change quoi que ce soit, puisque les doublons ne poussent surement pas le vice jusqu'à avoir le même p.id (ce serait grave !)
Xavier
(1) Ce que j'ai cherché à afficher, c'est la date du post. Si ce n'est pas le champ "posted", alors il faut le remplacer par celui qui va bien, y compris dans la clause GROUP BY.
(2) Je ne sais pas comment fonctionne punBB. J'ai fait comme si un utilisateur non enregistré était représenté par un posts.poster sans post.poster_id, mais si ce n'est pas le cas, il faudra adapter cette ligne
Dalida, je ne pense pas qu'un DISTINCT y change quoi que ce soit, puisque les doublons ne poussent surement pas le vice jusqu'à avoir le même p.id (ce serait grave !)
<<< Justement les doublons poussent le vice jusqu'a avoir le meme p.id ... j'en déduis donc que c'est grave, d'autant plus que l'ajout de DISTINCT pour le p.id ne résoud rien...
<<< Justement les doublons poussent le vice jusqu'a avoir le meme p.id ... j'en déduis donc que c'est grave, d'autant plus que l'ajout de DISTINCT pour le p.id ne résoud rien...
Hum je n'arrive pas a faire fonctionner la requete....
(il s'agit bien de posted pour la date et j'ai adapté puisque les posteurs non enregistrés ont l'id 1 et non un NULL)
Toutefois je suis convaincu qu'il n'y a pas de doublons car lorsque j'execute la requete sur le serveur directement, les posts qu'elle me sort en double ont le meme "p.id" donc le meme id...
L'id est un INDEX en autoincrement... j'ai verifié ensuite avec une requete manuelle du genre "SELECT * FROM posts WHERE id=999" pour verifier que par exemple le poste 999 (c'est un exemple) n'est pas en double... et dans la réponse il n'apparait qu'une fois...
(poster est le pseudo du poster, posted est la date et poster_id l'id du poster dont la valeur est 1 si il s'agit d'un post anonyme...)
(il s'agit bien de posted pour la date et j'ai adapté puisque les posteurs non enregistrés ont l'id 1 et non un NULL)
Toutefois je suis convaincu qu'il n'y a pas de doublons car lorsque j'execute la requete sur le serveur directement, les posts qu'elle me sort en double ont le meme "p.id" donc le meme id...
L'id est un INDEX en autoincrement... j'ai verifié ensuite avec une requete manuelle du genre "SELECT * FROM posts WHERE id=999" pour verifier que par exemple le poste 999 (c'est un exemple) n'est pas en double... et dans la réponse il n'apparait qu'une fois...
(poster est le pseudo du poster, posted est la date et poster_id l'id du poster dont la valeur est 1 si il s'agit d'un post anonyme...)
par contre pour le distinct je ne vois pas trop ou le caser :D
je pense qu'il reglerait le soucis puisque les ids sont les memes dans les posts en double
je pense qu'il reglerait le soucis puisque les ids sont les memes dans les posts en double
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question