le 16/06/2009 à 07:00
Problème système de profil en PHP + MySQL
C'est bien que tu ais trouvé, c'est mieux de partager la réponse.
LupusMic
-
SignatureDéveloppeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
-
Site web
-
Nombre de sujets26
-
Nombre de messages1 684
-
Nombre de commentaires4
-
Nombre de newsAucune
-
Niveau en PHPGourou
Ses derniers messages sur les forums
le 15/06/2009 à 23:12
Problème système de profil en PHP + MySQL
Et où est affecté $_SESSION['id'] ?
le 12/06/2009 à 21:25
resultat sondage
Moi non plus je n'utilises pas PDO :p mais j'ai utilisé les Statement SQL de MySQL. Mais on a tous le droit de se tromper !
le 12/06/2009 à 01:35
resultat sondage
Il va falloir que tu mettes en place un environnement de développement local.
Tes premiers sources ne seront pas sûrs, il faut que tu les testes en local avant de les publier.
Donc :
1- utilises un éditeur de texte qui permet la coloration syntaxique. Vim, Emacs, Scite, UltraEdit, etc.
2- installes un environnement web local. Je ne sais pas si tu travailles sous Microsoft Windows ou un Linux, mais il existe des solutions pour installer un environnement web sur toutes les plate-formes.
Quand à ton problème initial, effectivement, s'était la quote. Mais comme tu as dû le voir, avec la coloration syntaxique ça saute aux yeux. Alors que sans... c'est invisible !
Bon courage à toi.
Tes premiers sources ne seront pas sûrs, il faut que tu les testes en local avant de les publier.
Donc :
1- utilises un éditeur de texte qui permet la coloration syntaxique. Vim, Emacs, Scite, UltraEdit, etc.
2- installes un environnement web local. Je ne sais pas si tu travailles sous Microsoft Windows ou un Linux, mais il existe des solutions pour installer un environnement web sur toutes les plate-formes.
Quand à ton problème initial, effectivement, s'était la quote. Mais comme tu as dû le voir, avec la coloration syntaxique ça saute aux yeux. Alors que sans... c'est invisible !
Bon courage à toi.
le 11/06/2009 à 22:04
resultat sondage
(La Globule) Il n'y a pas besoin de quotes autour du marqueur « ? » dans les prepared statement.
Le code collé dans le premier message fait apparaître clairement une erreur de syntaxe (soit louée la coloration syntaxique). Est-ce que tu utilises un éditeur de texte qui colore ton source ?
Le code collé dans le premier message fait apparaître clairement une erreur de syntaxe (soit louée la coloration syntaxique). Est-ce que tu utilises un éditeur de texte qui colore ton source ?
le 11/06/2009 à 21:52
afficher certaines tables de la base
Parfois la documentation suffit à répondre à une question :)
Mais ici, c'est un peu plus délicat. Pour accéder pleinement au schéma d'une base de données, il suffit d'interroger la base mysql (si tu as le droit), ou la base virtuelle des
schéma MySQL.
Mais ici, c'est un peu plus délicat. Pour accéder pleinement au schéma d'une base de données, il suffit d'interroger la base mysql (si tu as le droit), ou la base virtuelle des
schéma MySQL.
le 09/06/2009 à 22:19
Session ? Ou pas?
Ça dépend du compromis que tu souhaites utiliser.
Stocker des données en session n'est pas un soucis, c'est fait pour ça. Si les données deviennent trop importante, il peut être utile de penser à des gestionnaires de session plus efficace, mais dans un premier temps c'est suffisant.
Donc de ce côté, pas d'inquiétude.
Par contre, l'inconvénient est que les données en session risquent d'être périmées. Donc les données cachées ne doivent qu'évoluer rarement en base. C'est un compromis qui peut être accordé aux droits d'accès.
Mais je ne pense pas que ton inquiétude concernant la quantité de données transmises soit justifiée. 50×20 octes (à tout casser), c'est rien.
Le conseil que je pourrais te donner, c'est de charger les données à chaque fois, puis d'envisager une optimisation par la suite, si c'est nécessaire.
Stocker des données en session n'est pas un soucis, c'est fait pour ça. Si les données deviennent trop importante, il peut être utile de penser à des gestionnaires de session plus efficace, mais dans un premier temps c'est suffisant.
Donc de ce côté, pas d'inquiétude.
Par contre, l'inconvénient est que les données en session risquent d'être périmées. Donc les données cachées ne doivent qu'évoluer rarement en base. C'est un compromis qui peut être accordé aux droits d'accès.
Mais je ne pense pas que ton inquiétude concernant la quantité de données transmises soit justifiée. 50×20 octes (à tout casser), c'est rien.
Le conseil que je pourrais te donner, c'est de charger les données à chaque fois, puis d'envisager une optimisation par la suite, si c'est nécessaire.
le 09/06/2009 à 21:37
afficher certaines tables de la base
le 09/06/2009 à 00:17
Problème de syntaxe
Il faut noter que cette notation est valable en PHP4, mais qu'elle est déconseillée au-delà.
le 07/06/2009 à 15:39
recherche multiple dans table bdd
Lit la documentation de select, surtout ce qui concerne like.
Le problème est que tu ne comprends pas ce que tu fais, du coup, tu ne peux pas comprendre le résultat.
C'est une erreur d'interprétation de ta part. La clause like attends un motif de recherche. Si le champ 'annee' de ton formulaire est vide, alors $_POST['annee'] contiendra une chaîne vie (''). Ce n'est pas ' '. Du coup, la requête SQL construite correspondra à ceci (j'ignore code_ce) :
Comme on peut aisément comprendre de cette requête, tout les occurrences d'annee correspondant à n'importe quel caractère va correspondre. Du coût, l'ensemble des tuples seront retournés par le serveur MySQL.
Lis la documentation sur select.
Il faut aussi que tu acquière la logique booléenne. Google est ton ami pour ça. Mais en gros :
true and true = true
false and true = false
true and false = false
false and false = false
true or true = true
true or false = true
false or true = true
false or false = false
Ceci est pour la base. Mais il faut aussi considérer plusieurs concepts :
* Protéger les données soumises via formulaire (voir mysql_real_escape_strin)
* Éviter like autant que possible. Like est très inefficace, surtout pour les champs de date.
* Construction conditionnelle de la requête. Si un champ du formulaire doit être ignoré lorsqu'il est vide, la clause where doit être construite par étapes.
Voilà pour l'essentiel.
Le problème est que tu ne comprends pas ce que tu fais, du coup, tu ne peux pas comprendre le résultat.
« comme si la valeur " " était contenu dans le champ de la table »
C'est une erreur d'interprétation de ta part. La clause like attends un motif de recherche. Si le champ 'annee' de ton formulaire est vide, alors $_POST['annee'] contiendra une chaîne vie (''). Ce n'est pas ' '. Du coup, la requête SQL construite correspondra à ceci (j'ignore code_ce) :
SELECT Id_rando, rando FROM $table WHERE annee LIKE '%%' Order by Id_rando Asc
Comme on peut aisément comprendre de cette requête, tout les occurrences d'annee correspondant à n'importe quel caractère va correspondre. Du coût, l'ensemble des tuples seront retournés par le serveur MySQL.
Lis la documentation sur select.
Il faut aussi que tu acquière la logique booléenne. Google est ton ami pour ça. Mais en gros :
true and true = true
false and true = false
true and false = false
false and false = false
true or true = true
true or false = true
false or true = true
false or false = false
Ceci est pour la base. Mais il faut aussi considérer plusieurs concepts :
* Protéger les données soumises via formulaire (voir mysql_real_escape_strin)
* Éviter like autant que possible. Like est très inefficace, surtout pour les champs de date.
* Construction conditionnelle de la requête. Si un champ du formulaire doit être ignoré lorsqu'il est vide, la clause where doit être construite par étapes.
Voilà pour l'essentiel.
