la requete en question:

 
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.

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...

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 ??

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.

bon alors je te fais confiance ca vient pas de ton script ....
 
commence par eclaircir ta requete car c'est un peu le souk
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]

ok, merci, mais j'ai trouvé le bug: MULTIMANIA 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

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...

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

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

 
Ben donne un exemple de belles requetes

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

 
rhoo comme t'es pas a jour
 
mysql_fetch_array est devenu aussi rapide que mysql_fetch_row depuis php 4.0.6, évidemment comme tu travailles en php3 ...
Et les jointure elle sont aussi rapides que si je séparais le code en plusieurs requètes.

 
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)    
 
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"      
 
joce il est ou ton code qu'on rigole un petit coup    

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

gizmo a écrit a écrit :     rhoo comme t'es pas a jour   mysql_fetch_array est devenu aussi rapide que mysql_fetch_row depuis php 4.0.6, évidemment comme tu travailles en php3 ... 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 )
Nan le code c'est du fully php4, et HFR tourne avec php 4.1.0 d'ailleurs

potiron a écrit a écrit :   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)       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"         joce il est ou ton code qu'on rigole un petit coup

mon code source je le garde
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

potiron a écrit a écrit :   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)       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"         joce il est ou ton code qu'on rigole un petit coup

 
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
Ca fait deux semaines qu'on se prends la tête avec Monty pour le débugger