le 11/03/2008 à 11:30
Forcer le téléchargement d'un pdf
Quand tu écris un message, y'a un lien "bb-code", clic dessus (c'est écrit dans les conditions d'utilisation du forum en plus...).
LA GLOBULE
Inscris le 25/09/2002 à 10:40
-
Site web
-
Nombre de sujets47
-
Nombre de messages8 345
-
Nombre de commentaires142
-
Nombre de news8 346
-
Niveau en PHPExcellent
Ses derniers messages sur les forums
le 11/03/2008 à 10:06
Probleme de jointure innoDB
LupusMic, cela m'intéresse : quand tu as une clé étrangère, tu peux te passer du ON ou du USING ? Comment MySQL comprend sur quel champ tu veux faire la jointure ? (rien ne m'oblige à faire une jointure sur une clé).
le 11/03/2008 à 10:04
Problème de restauration BDD avec sauvegarde DUMP
Et dans l'URL, tu ne vois pas quel fichier est chargé ?
le 11/03/2008 à 00:30
select where = all
Ben si $_GET['categorie'] vaut All, tu exécutes sans condition sur la catégorie, c'est tout.
Mais ta question te trahis. En effet, on voit bien que tu prends ce que tu reçois dans $_GET['categorie'], tu le colles à ta requête SQL sans vérifier ce que tu reçois dans cette variable (si tu vérifiais tes paramètres, tu ne poserais même pas cette question).
Et en plus, tu n'escapes pas ta requête SQL : en gros, tu joues avec le feu la.
Donc mes conseils :
- avant de forger ta requete, clean ton paramètre $_GET['categorie'] : regarde ce que tu y recois (All ? ou bien une catégorie valide ? etc.)
- si tu recois 'All', alors crée une requete sans condition sur l'attribut categorie. A priori, All veut dire "aucune catégorie spécifiée (ex. if ($test == 'all') $sql = 'requete sans condition sur categorie'; else $sql = 'requete avec condition sur categorie';). Mais bon, après tout depend de ta base, et tu auras peut etre un OR massif à faire comme tu comptais le faire, mais la, tu es le seul à pouvoir le savoir.
- escape ta requete, des fonctions sont la pour ca, comme mysql_escape_string, et entoure ton test SQL avec des quotes (sinon, MySQL croit recevoir un INT et non une chaine de caractère. ex : WHERE blu = 'polom' << MySQL doit recevoir ca et non WHERE blu = polom)
Mais ta question te trahis. En effet, on voit bien que tu prends ce que tu reçois dans $_GET['categorie'], tu le colles à ta requête SQL sans vérifier ce que tu reçois dans cette variable (si tu vérifiais tes paramètres, tu ne poserais même pas cette question).
Et en plus, tu n'escapes pas ta requête SQL : en gros, tu joues avec le feu la.
Donc mes conseils :
- avant de forger ta requete, clean ton paramètre $_GET['categorie'] : regarde ce que tu y recois (All ? ou bien une catégorie valide ? etc.)
- si tu recois 'All', alors crée une requete sans condition sur l'attribut categorie. A priori, All veut dire "aucune catégorie spécifiée (ex. if ($test == 'all') $sql = 'requete sans condition sur categorie'; else $sql = 'requete avec condition sur categorie';). Mais bon, après tout depend de ta base, et tu auras peut etre un OR massif à faire comme tu comptais le faire, mais la, tu es le seul à pouvoir le savoir.
- escape ta requete, des fonctions sont la pour ca, comme mysql_escape_string, et entoure ton test SQL avec des quotes (sinon, MySQL croit recevoir un INT et non une chaine de caractère. ex : WHERE blu = 'polom' << MySQL doit recevoir ca et non WHERE blu = polom)
le 10/03/2008 à 23:10
Problème de restauration BDD avec sauvegarde DUMP
Dans le code source du site.
Le mieux serait d'afficher cette requête à l'écran (c'est à dire telle qu'elle est envoyée à MySQL, après génération éventuelle en PHP).
Quand ton SQL ERROR s'affiche à l'écran, tu ne vois aucune indication concernant le fichier ou se trouve l'erreur ? Voir la ligne du fichier ?
Le mieux serait d'afficher cette requête à l'écran (c'est à dire telle qu'elle est envoyée à MySQL, après génération éventuelle en PHP).
Quand ton SQL ERROR s'affiche à l'écran, tu ne vois aucune indication concernant le fichier ou se trouve l'erreur ? Voir la ligne du fichier ?
le 10/03/2008 à 22:57
Problème de restauration BDD avec sauvegarde DUMP
Oui, ok, mais comme je te dis, c'est la requête qui est exécuté qui est le plus important : c'est elle qui contient le bug, c'est pas la base en elle même. Sans cette requête, on ne pourra pas t'aider.
le 10/03/2008 à 22:43
Problème de restauration BDD avec sauvegarde DUMP
Non justement, le problème se pose sur une requete où une opération est faite sur un certain 'is_dynamic', mais ce 'is_dynamic' n'existe justement pas dans la table en question (table ou s'effectue la requête).
Le message d'erreur le dit : "champ is_dynamic inconnu au bataillon".
Le message d'erreur le dit : "champ is_dynamic inconnu au bataillon".
le 10/03/2008 à 22:07
Problème de restauration BDD avec sauvegarde DUMP
Et comment sais tu que la requête porte sur cette table ? Peux tu nous donner cette requête ?
le 10/03/2008 à 19:33
Problème de restauration BDD avec sauvegarde DUMP
Faudrait voir entièrement la requête pour se prononcer. Mais en gros, la requête SQL utilise un champ qui n'existe pas en base de données.
Alors certes le champ id_dynamic existe peu être sur une table, mais ce n'est pas sur cette table que porte cette requête (sinon, tu n'aurais pas l'erreur).
Alors certes le champ id_dynamic existe peu être sur une table, mais ce n'est pas sur cette table que porte cette requête (sinon, tu n'aurais pas l'erreur).
le 10/03/2008 à 14:27
Utiliser une class dans une autre class
Ben si tu instancies un objet dans ta classe, cela fonctionne.
T'as du merder un truc.
Exemple :
Fonctionne sans soucis.
En gros, tu ne dois pas instancier $db dans le haut de ta page car il ne sera pas accessible dans ta classe.
T'as du merder un truc.
Exemple :
<?php
class pom {
var $toto = 3;
}
class blu {
function polom() {
$obj = new pom();
echo $obj->toto;
}
}
$pouf = new blu();
$pouf->polom();
?>
Fonctionne sans soucis.
En gros, tu ne dois pas instancier $db dans le haut de ta page car il ne sera pas accessible dans ta classe.
