Bonjour,

Je voudrais récupérer dans une table une date déjà formatée à la française : je teste donc la commande SQL DATE_FORMAT.

Voici mon test 1 (qui marche) : Par contre, si j'utilise mysql_fetch_array au lieu de mysql_fetch_row, ça ne marche plus quans j'écris ceci : J'ai une erreur "Undefined index: CS_DateCS "
Savez-vous pourquoi ? Ai-je fait une grossière erreur ou est-il impossible d'utiliser DATE_FORMAT avec mysql_fetch_array ?

merci d'avance
Corinne

hello,

tu as plusieurs options :

1 tu fais un print_r( $ligne ) pour savoir comment est libellé ton champ

2 tu utilise les alias : SELECT DATE_FORMAT( ... ) AS madate...
et tu récuperera ta date dans $ligne['madate']

Effectivement, si tu appliques une fonction sur un champ, tu ne peux plus récupérer le résultat par le nom du champ.
Il te faut donc utiliser un alias et récupérer la valeur de cet alias

OK merci pour l'info.
Corinne

Si mysql_fetch_array() est identique à odbc_fetch_array(), ce que je suppose, alors ton tableau "$ligne" n'est pas composé des noms de tes champs mais d'un indice chiffré, soit :

<?php

$query="SELECT CS_CodeEnfant, DATE_FORMAT(CS_DateCS, '%d-%m-%Y') FROM consultations WHERE CS_id='9'";
$result = mysql_query($query)or die ('Erreur SQL!<br>'.$sql.'<br>'.mysql_error());
$ligne = mysql_fetch_array($result);
echo "Enfant : ".$ligne[0]." date : ".$ligne[1];

?>

Vérifie

Bien que j'ai l'impression que ca est réglé ton problème, j'ai été voir la "fiche technique" de mysql_fetch_array() et en fait les 2 cas sont possibles tout dépend la valeur du paramètre que l'on ajoute à cette fonction :

$result = mysql_query("SELECT id, name FROM mytable");

while ($row = mysql_fetch_array($result, MYSQL_NUM)) {
   printf("ID : %s  Nom : %s", $row[0], $row[1]);
}

while ($row = mysql_fetch_array($result, MYSQL_ASSOC)) {
   printf("ID : %s  Nom : %s", $row["id"], $row["name"]);
}

while ($row = mysql_fetch_array($result, MYSQL_BOTH)) {
   printf ("ID : %s  Nom : %s", $row[0], $row["name"]);
}

Donc si tu est en MYSQL_ASSOC, tu devra créer un alias comme dit dans les post précédent, et sinon tu peux attaquer par l'indice ...

Si je puis me permettre, c'est une très mauvaise idée de préférer mysql_fetch_row() à mysql_fetch_array()

Imagine que tu utilises un code de ce type là :

$str_requete = "SELECT
					*
				FROM
					users";
$o_result = mysql_query($str_requete) or die("Erreur MySQL : " . mysql_error() . "\nRequête : " . $str_requete);

while ( $a_result = mysql_fetch_row($o_result) )
{
	$nom 		= $a_result[0];
	$adresse 	= $a_result[1];
	$ville 		= $a_result[2];
}

Sur un table de ce type Le jour où tu veux ajouter le champ "prenom" entre "nom" et "adresse", tu fait exploser ton code

Si je puis me permettre, moi aussi, n'est-il pas déconseillé d'utiliser "SELECT * ...", entre autre pour les raisons que tu as indiquées Zeus ?
Si on formatte correctement sa requête du coup il n'y a plus le problème de l'utilisation d'un indice ... nan ?
De plus dans une requete, si le libelle du champ change, tu ne modifie que dans la requete lorsque tu utilises des indices. En utilisant les libellés des champs tu devras modifier son utilisation partout...
Aussi si le champ change de place dans la table, ce n'est pas un problème puisque c'est la requete qui formate la sortie.
Et enfin, je suis quand même d'accord pour dire que c'est moins lisible, bien que ce soit plus souple, d'utiliser des indices puisqu'il faut soit connaitre par coeur les champs de la requête (alors l'indice 12 c'est pour le prénom et le 34 c'est pour le celui de son chien) soit tout le temps remonter au niveau de la requête et compter ...

Disons que, tant qu'a être optimisé, autant l'être jusqu'au bout

Les règles que je m'impose sont les suivantes :
- toujours lister les champs que j'utilise dans les requêtes (pas de SELECT *, effectivement. C'est ausi mauvais pour les performances qu'inutile)
- toujours utiliser un mysql_fetch_array pour nommer explicitement le champ que je récupère.
- Garder au maximum un ordre logique dans les champs. Dans mon exemple précédent, je met le champ "Prenom" après le champ "Nom" et pas à la fin de la table.

Le plus important c'est d'être le plus clair possible dans son code, et pas seulement pour soi, nan ?
Donc toute méthode est bonne à prendre à partir du moment où elle est un minimum optimisée et compréhensible par tous, je me trompe ?
A mon avis ta technique est la plus claire, mais moi j'ai pris l'habitude de odbc_fetch_into qui renvoi des indices.
Pour palier à ce "problème" je crée des variables dans lesquelles j'insères les différentes valeurs de ma requete dès le début. Comme ca après je ne travaille qu'avec ces valeurs => si ma requete change, il ne me suffit que de changer le début
Est-ce une perte de temps ? devrais-je passer par une autre fonction pour récupérer mes résultats ?

Pour palier à ce "problème" je crée des variables dans lesquelles j'insères les différentes valeurs de ma requete dès le début. Comme ca après je ne travaille qu'avec ces valeurs => si ma requete change, il ne me suffit que de changer le début
Est-ce une perte de temps ? devrais-je passer par une autre fonction pour récupérer mes résultats ?

Il n'en reste pas moins que, pour ne pas avoir à décaler tout tes indices, dès que tu ajoutes un champs à ton SELECT, il faut qu'il soit à la fin.
Alors que ma méthodologie n'est pas impactée par la modification de l'ordre des champs dans le SELECT