[MySQL] Réaction bizarre d'une requete

Recherche :

Dernière réponse

Sujet : [MySQL] Réaction bizarre d'une requete

joce

gizmo a écrit a écrit :

non, bien sur que je n'en ai pas besoin, mais comme je dois faire en sorte que cela fonctionne avec toutes les version de php 4, je dois parfois faire des actions un peu redondandes. Enfin de tout facon, j'ai réussi a arranger cette partie sans MYSQL_ASSOC.

joce>> c'est quoi ce principe de mise en cache de MySQL 4.0.1?

ahah :D
Ca fait deux semaines qu'on se prends la tête avec Monty pour le débugger :o

Votre réponse

Nom d'utilisateur

Pour poster, vous devez être inscrit sur ce forum .... si ce n'est pas le cas, cliquez ici !

Le ton de votre message

Votre réponse

Smilies

Liste des smilies perso
Wiki smilies
Chercher un smiley

Options

Activer votre signature
Désactiver les smilies
Activer la notification par email du sujet

Aperçu

Vous avez perdu votre mot de passe ?

Vue Rapide de la discussion

joce

ahah :D
Ca fait deux semaines qu'on se prends la tête avec Monty pour le débugger :o

gizmo

potiron a écrit a écrit :

:D
tu as pas tort pour la vitesse mais c'est moins lisible !
c'est ce que j'essayais de te faire comprendre ..

oui aussi pour mysql_fetch_array mais si tu as pas besoin de sortir tes vars dans tab associatif ET DANS tab a index evite le, tu grilles des ressources pour rien surtout si c'est pour utiliser un mysql_fetch_array($ressource,MYSQL_ASSOC) :heink: :na:

en plus tu precises dans ton message, je cite : "mysql_fetch_array est devenu aussi rapide que mysql_fetch_row depuis php 4.0.6" hors tu dis aussi, je cite :"multimania utilisent le 4.0.4pl1" :heink: :ange:

joce il est ou ton code qu'on rigole un petit coup :lol: :na: :ange:

non, bien sur que je n'en ai pas besoin, mais comme je dois faire en sorte que cela fonctionne avec toutes les version de php 4, je dois parfois faire des actions un peu redondandes. Enfin de tout facon, j'ai réussi a arranger cette partie sans MYSQL_ASSOC.

joce>> c'est quoi ce principe de mise en cache de MySQL 4.0.1?

joce

mon code source je le garde :D
Allez, cadeau :

// on utilise $auteurstr dans la requète afin qu'elle soit dans tous les cas mise en cache par MySQL 4.0.1 et supérieur (les requètes doivent être strictement identiques)

ca vous avance vachement hein :D

joce

gizmo a écrit a écrit :

rhoo comme t'es pas a jour :D

mysql_fetch_array est devenu aussi rapide que mysql_fetch_row depuis php 4.0.6, évidemment comme tu travailles en php3 :p ...
Et les jointure elle sont aussi rapides que si je séparais le code en plusieurs requètes.

C'est pas parce que le fichier a l'extension .php3 que c'est du php3 (je sais c'est pas logique :lol:)
Nan le code c'est du fully php4, et HFR tourne avec php 4.1.0 d'ailleurs :p

potiron

:D
tu as pas tort pour la vitesse mais c'est moins lisible !
c'est ce que j'essayais de te faire comprendre ..

oui aussi pour mysql_fetch_array mais si tu as pas besoin de sortir tes vars dans tab associatif ET DANS tab a index evite le, tu grilles des ressources pour rien surtout si c'est pour utiliser un mysql_fetch_array($ressource,MYSQL_ASSOC) :heink: :na:

en plus tu precises dans ton message, je cite : "mysql_fetch_array est devenu aussi rapide que mysql_fetch_row depuis php 4.0.6" hors tu dis aussi, je cite :"multimania utilisent le 4.0.4pl1" :heink: :ange:

joce il est ou ton code qu'on rigole un petit coup :lol: :na: :ange:

[edtdd]--Message édité par potiron--[/edtdd]

gizmo

joce a écrit a écrit :

rô les jointures pas belles :D
Rô mysql_fetch_array !
Je préfère mon code :D

rhoo comme t'es pas a jour :D

mysql_fetch_array est devenu aussi rapide que mysql_fetch_row depuis php 4.0.6, évidemment comme tu travailles en php3 :p ...
Et les jointure elle sont aussi rapides que si je séparais le code en plusieurs requètes.

Kyle

joce a écrit a écrit :

rô les jointures pas belles :D
Rô mysql_fetch_array !
Je préfère mon code :D

Ben donne un exemple de belles requetes :D

joce	rô les jointures pas belles :D Rô mysql_fetch_array ! Je préfère mon code :D

gizmo

potiron a écrit a écrit :

alors utilise plutot mysql_fetch_assoc plutot que de rajouter un isset

j'ai testé aussi, mais le résultat était le même. Le bug n'a été corrigé qu'avec php 4.0.5 et ils utilisent le 4.0.4pl1 :/ au lieu de foutre des bannières gigantesques, ils feraient mieux de mettre a jour leurs versions...

potiron

alors utilise plutot mysql_fetch_assoc plutot que de rajouter un isset

gizmo

ok, merci, mais j'ai trouvé le bug: MULTIMANIA :fou: c'est leur version de php qui est vieille et comporte un bug qui fait que MYSQL_ASSOC n'est pas pris en compte dans mon mysql_fetch_array. Résultat, il ne réinitialisait pas mes valeurs correctement et écrasait mes mises a niveau dans la boucle. J'ai résolu le problème avec un isset.

PS: elle est tres clair ma requète :na:

potiron

bon alors je te fais confiance ca vient pas de ton script ....

commence par eclaircir ta requete car c'est un peu le souk :heink:
evite les alliases sur les noms des tables, ca embrouille et apporte rien de concret ..

quand j'ai des grosses requetes voici ce que je fait, je te met un extrait d'un de mes scripts :
---------------------------------------------
// --- REQ POUR AFFICHAGE INFOS FORMATEUR+FACTURE SESSION ---
$colo="session.idsession ,";
$colo.="DATE_FORMAT(session.boncommande,'%d-%m-%y') AS boncommande ,";
$colo.="session.idhotel ,";
$colo.="session.hotelreserve ,";
$colo.="session.idformateur ,";
$colo.="DATE_FORMAT(session.debut,'%d-%m-%y') AS debut ,";
$colo.="formation.logiciel ,";
$colo.="formation.intitule ,";
$colo.="factureformateur.idfactureformateur ,";
$colo.="DATE_FORMAT(factureformateur.datepayement,'%d-%m-%y') AS datepayement ,";
$colo.="formateur.idformateur ,";
$colo.="formateur.nom ,";
$colo.="formateur.commentaire, ";
$colo.="CASE WHEN session.debut>NOW() THEN 0 ELSE 1 END AS facbon" ;
// ---------- ----------
$where="factureformateur.datepayement='0000-00-00' AND ";
$where.="session.idsession=factureformateur.idsession AND ";
$where.="factureformateur.idformateur=formateur.idformateur AND ";
$where.="session.idformation=formation.idformation";
// ---------- ----------
$req="select $colo from session,formation,formateur,factureformateur where $where";
$con=mysql_query($req);
---------------------------------------------

la j'ai pas beaucoup de table donc je fait pas le meme principe que $colo ou $where mais c'est aussi faisable -> a la fin ca te donne un code tres propre et surtout tres lisible .

pour revenir a ta requete, regarde ici :
LEFT JOIN utilisateurs U ON U.id=P.auteur_id
LEFT JOIN utilisateurs U2 ON U2.id=P.editeur_id

ca me parrait bizarre meme si je connais pas la facon dont tu as creer les liens entre tes tables .

[edtdd]--Message édité par potiron--[/edtdd]

gizmo

j'utilise un mysql_fetch_array. J'ai déja essayé de réinitialiser les valeurs après leur utilisation dans le while, mais ca ne change rien. Comme si la requete avait remplacé les valeurs dans les champs vides suivants tant qu'elle n'en trouve pas un nouveau qui soit rempli.

potiron

vu ce que tu dis, le probleme vient pas de la requete mais de ton code PHP !!

tu extrait comment les vars ?

mysql_fetch_assoc ?
mysql_fetch_row ?
mysql_fetch_object ?

et ensuite ??

ethernal

bizarre en effet, il me semble avoir déja eu le cas aussi

ta boucle while contient quoi ?
tu peux essayer de remmettre à "" tes variables après affichage...

gizmo

la requete en question:

Code :

mysql_query("SELECT P.id,P.moment,P.texte,U2.login AS editeur,P.signature AS sign,U.signature,U.id AS who,U.login,P.icone,U.icq,U.msn,U.aim,U.yahoo FROM $table_post AS P
LEFT JOIN utilisateurs U ON U.id=P.auteur_id
LEFT JOIN utilisateurs U2 ON U2.id=P.editeur_id
WHERE P.sujet='$topic'
LIMIT $debut,$forum_mpp" );

le problème c'est que la valeur de icq,aim,yahoo et msn peuvent etre vide et dans ces cas la, il les remplace par la valeur précédente non nulle, dans ma boucle while. Ce qui fait que tout est faussé dans mes affichages.