8797 sujets

Développement web côté serveur, CMS

[Résolu]Erreur de mysql_fetch_assoc()

Bonjour,

je reviens une nouvelle fois vers vous pour une erreur étrange.

J'ai une requete SQL qui me permet d'afficher une liste de matériels disponibles pour une date de départ et une date de retour données, en fonction de la famille choisie :


$req_materieldispo = 
"SELECT [...]
FROM reservation, famille, materiel
WHERE famille.NomFamille = '" . $NomFamilleSelect . "'
AND famille.NuFamille = materiel.NuFamille
AND materiel.NuMateriel = reservation.NuMateriel
AND '" . $timestamp_retour . "' < reservation.DateDepartReservation
AND '" . $timestamp_depart . "' > reservation.DateRetourReservation 
UNION
SELECT [...]
FROM famille, materiel
WHERE famille.NomFamille = '" . $NomFamilleSelect . "'
AND famille.NuFamille = materiel.NuFamille
AND materiel.NuMateriel NOT IN
(SELECT reservation.NuMateriel FROM reservation)
ORDER BY CodePosteMateriel ASC" or die(mysql_error());



Pour une de mes applications, un echo de cette requete me donne ceci :

SELECT [...]
FROM reservation, famille, materiel
WHERE famille.NomFamille = 'Laptop'
AND famille.NuFamille = materiel.NuFamille
AND materiel.NuMateriel = reservation.NuMateriel
AND '1230551580' < reservation.DateDepartReservation
AND '1230465180' > reservation.DateRetourReservation
UNION
SELECT [...]
FROM famille, materiel
WHERE famille.NomFamille = 'Laptop'
AND famille.NuFamille = materiel.NuFamille
AND materiel.NuMateriel NOT IN
(SELECT reservation.NuMateriel FROM reservation)
ORDER BY CodePosteMateriel ASC

Je copie/colle ce texte dans mon invite SQL pour tester ma requête et celle-ci fonctionne correctement, j'ai l'affichage souhaité.

Par contre, lorsque je la passe en PHP, et que je souhaite afficher le contenu de cette requete, j'ai le droit au magnifique Warning: mysql_fetch_assoc(): supplied argument is not a valid MySQL result resource in C:\Documents and Settings\Administrateur\Bureau\Site\pages\resa.php on line 351

Ma ligne 351 ne me semble pas erronée, elle n'est qu'un copié/collé d'autres appels effectués précédement et qui fonctionnent, eux !

while ($tab_materieldispo = mysql_fetch_assoc($req_materieldispo)){	
.
.
.
}


Quelqu'un a t'il une idée quand à la résolution de mon problème ?
Modifié par Killaman (10 Dec 2008 - 11:42)
Salut,
Tu as oublié l'étape du mysql_query Smiley cligne
En l'état, $req_materieldispo est une chaîne de caractères.
$req_materieldispo = "SELECT [...]"; // sans [b]or die[/b], inutile ici
$rs = @mysql_query($req_materieldispo, $link); // $link est ta ressource de connexion
// pas de [b]or die[/b] non plus, c'est moche
if (!$rs)
{
    echo 'échec de la requête<br>' . $req_materieldispo . '<br>' . mysql_error();
}
else
{
    while ($tab_materieldispo = @mysql_fetch_assoc($rs))
    {
        // ...
    }
}

a+
Salut,

jeje a écrit :

// pas de or die non plus, c'est moche
Est-ce que tu veux dire que même en phase de développement tu ne l'utilises jamais ?
Heyoan a écrit :
Est-ce que tu veux dire que même en phase de développement tu ne l'utilises jamais ?

En fait, la question ne se pose même pas parce que je ne fais pas directement de mysql_*, tout ça est géré par un objet qui lui fait les choses proprement.
Libre à moi d'activer le mode verbose si je veux debugger : les requêtes et leur état sont stockées dans l'objet pour être affichées en fin de page, ou en commentaires html si ça flingue l'affichage (là j'avoue, c'est du zèle).

Pour savoir, vous en faites quoi de vos or die une fois en déploiement ?
jeje a écrit :

En fait, la question ne se pose même pas parce que je ne fais pas directement de mysql_*, tout ça est géré par un objet qui lui fait les choses proprement.
Ah oui... effectivement. Smiley langue

jeje a écrit :

Pour savoir, vous en faites quoi de vos or die une fois en déploiement ?
Ben si je n'oublie pas je les vire.
Heyoan a écrit :
Ben si je n'oublie pas je les vire.

Et à la place tu ne mets pas un mécanisme de protection, un petit test au moins ?

Je veux bien qu'une fois la requête blindée, on est tranquille question erreurs de syntaxe, mais si la connexion à la base a échoué, la requête échoue également, et sans protection on est marron (ou alors tu mets des @ partout, mais ça ne doit pas garantir dans tous les cas la validité du code HTML produit (je pense notamment aux listes ouvertes avant de tester si on a au moins un item à y placer))
Eh bien globalement je mets ça en phase de dev
error_reporting(E_ALL);
que je remplace ensuite par 
error_reporting(0);


Pour ce qui est de la connexion j'ai quelque chose du genre
<?php
$link = mysql_connect('host', 'user', 'pwd');
if (!$link) {
   die('Erreur de connexion au serveur. Merci de contacter johndoe@fai.com si le problème persiste.');
}

// Rendre la base de données foo, la base courante
$db_selected = mysql_select_db('mabase', $link);
if (!$db_selected) {
   die ('Erreur de connexion à la base de données. Merci de contacter johndoe@fai.com si le problème persiste.');
}
?>
C'est d'ailleurs le seul endroit où je laisse trainer le "die" mais comme je n'ai jamais reçu de mail c'est resté en l'état. Smiley biggol

Pour ce qui est d'une requête qui risque de ne rien ramener j'utilise systématiquement mysql_num_rows (avant d'ouvrir ma liste Smiley cligne ).
oki, moi j'ai arrêté de procéder ainsi afin de fournir une page HTML valide quoi qu'il arrive.

Ainsi, et surtout pour une appli web, je teste la connexion/sélection à la db d'entrée de jeu, ce qui me permet d'afficher une page d'indisponibilité de l'appli en gardant l'identité visuelle (et pas un aspect texte brut avec juste un message d'erreur). J'affichais cette page d'erreur dans le die à une époque, un peu lourd quand même, même si cette page est générée par une fonction.

Pour les sites (en fait, "le" site Smiley langue , le web c'est pas mon métier), c'est mode discret, un simple message disant qu'il n'y a pas d'infos à afficher. C'est surtout parce qu'il y a des parties statiques, ou ne dépendant pas de mysql, donc je ne peux pas me permettre de killer toutes les pages.

La POO a grandement amélioré la gestion de tout ce bordel Smiley cligne
Modifié par jeje (09 Dec 2008 - 21:20)
jeje a écrit :
Ainsi, et surtout pour une appli web, je teste la connexion/sélection à la db d'entrée de jeu, ce qui me permet d'afficher une page d'indisponibilité de l'appli en gardant l'identité visuelle (et pas un aspect texte brut avec juste un message d'erreur).

+1

Je ne trouve pas ça très pro d'afficher une page d'erreur incompréhensible à l'utilisateur.
jeje a écrit :

Ainsi, et surtout pour une appli web, je teste la connexion/sélection à la db d'entrée de jeu, ce qui me permet d'afficher une page d'indisponibilité de l'appli en gardant l'identité visuelle (et pas un aspect texte brut avec juste un message d'erreur).
C'est clair que c'est plus soigné que le die... je me note ça dans la TODO List Smiley cligne .

jeje a écrit :

La POO a grandement amélioré la gestion de tout ce bordel Smiley cligne
En fait je m'en sers aussi de plus en plus mais je n'ai encore jamais pris le temps de tester quelque chose comme PDO...
et +1 dans la TODO List Smiley lol
Merci à tous, ça fonctionne.

Je ne saisie pas trop pourquoi sur les autres requetes d'affichage de tableau, ça fonctionnait sans le "@mysql_query" donnée par jeje, donc si vous pouviez (une dernière fois Smiley rolleyes ) éclairer ma lanterne ?

Merci
Bon OK, je vois qu'au bout de 3-4h de codage, il vaut mieux prendre une pause que de rester dans son imbécilité...

Je viens de me rendre compte que le post ci dessus donnait une piètre image de mon savoir en php... Smiley sweatdrop

Bien sûr que si, j'avais mis des mysql_query !!! (idiot que je suis !) Et j'ai perdu une demi après-midi sur cette erreur...

Bon, une pause s'impose !

Merci encore une fois
Sujet clos
Aller à