Requête SQL ne fonctionne pas
werxetcryvgu
Messages postés
3
Date d'inscription
Statut
Membre
Dernière intervention
-
yg_be Messages postés 23541 Date d'inscription Statut Contributeur Dernière intervention -
yg_be Messages postés 23541 Date d'inscription Statut Contributeur Dernière intervention -
Bonjour,
Je code une appli web en local qui fonctionne super bien, mais une fois en ligne, certaine requêtes ne fonctionnent pas:
Celles-ci fonctionnent par contre:
En gros quand j'utilise query() c'est bon mais pas avec prepare() / execute(), d'ailleurs je ne suis pas un pro du code (j'apprend avec les tutos sur le web), je n'ai pas saisi la différence entre ces deux structures et dans quel cas les appliquer.
Merci d'avance pour vos réponses.
Je code une appli web en local qui fonctionne super bien, mais une fois en ligne, certaine requêtes ne fonctionnent pas:
$sql="INSERT INTO users VALUES ('', '$lname', '$fname', '$email','$password', '$level')";
$query=$DB->prepare($sql);
$res=$query->execute();
Celles-ci fonctionnent par contre:
$req= $DB->query("SELECT id FROM users WHERE email='$email' LIMIT 1");
$user=$req->fetch();
En gros quand j'utilise query() c'est bon mais pas avec prepare() / execute(), d'ailleurs je ne suis pas un pro du code (j'apprend avec les tutos sur le web), je n'ai pas saisi la différence entre ces deux structures et dans quel cas les appliquer.
Merci d'avance pour vos réponses.
A voir également:
- Requête SQL ne fonctionne pas
- Logiciel sql - Télécharger - Bases de données
- Sql lister les tables ✓ - Forum Programmation
- Ora-00933: la commande sql ne se termine pas correctement ✓ - Forum Oracle
- Requête bloquée par le pare-feu applicatif claranet webfence ✓ - Forum Réseaux sociaux
- Quelle requête écrire pour demander au moteur de recherche de présenter de préférence les pages web traitant de tennis mais pas de tennis de table ✓ - Forum Java
2 réponses
yg_be
Messages postés
23541
Date d'inscription
Statut
Contributeur
Dernière intervention
Ambassadeur
1 584
bonjour, "ne fonctionnent pas": peux-tu être plus précis?
il est indispensable de détecter et réagir aux erreurs: https://forums.commentcamarche.net/forum/affich-37584941-php-pdo-gerer-les-erreurs
cela t'aidera à comprendre ce qui ne fonctionne pas.
tu peux utiliser query (pour des select) et exec (pour des insert, update et delete).
tu peux aussi utiliser, pour les deux, prepare/execute.
prepare/execute facilite l'insertion de données variables dans les requêtes, comme tu l'auras lu dans l'explication à propos de la gestion des erreurs.
l'utilisation de prepare/execute est plus performant que query ou exec quand tu peux faire un prepare et plusieurs execute.
il est indispensable de détecter et réagir aux erreurs: https://forums.commentcamarche.net/forum/affich-37584941-php-pdo-gerer-les-erreurs
cela t'aidera à comprendre ce qui ne fonctionne pas.
tu peux utiliser query (pour des select) et exec (pour des insert, update et delete).
tu peux aussi utiliser, pour les deux, prepare/execute.
prepare/execute facilite l'insertion de données variables dans les requêtes, comme tu l'auras lu dans l'explication à propos de la gestion des erreurs.
l'utilisation de prepare/execute est plus performant que query ou exec quand tu peux faire un prepare et plusieurs execute.
Ok merci je vais regarder avec la gestion des erreurs.
Pour être plus précis, j'utilise 2 requêtes avec la structure prepare()/execute() dans mon code l'un pour créer un nouvel utilisateur (INSERT) l'autre pour en supprimer un (DELETE).
A part dans ces deux cas, toutes mes requêtes fonctionnent en utilisant query().
Pour être plus précis, j'utilise 2 requêtes avec la structure prepare()/execute() dans mon code l'un pour créer un nouvel utilisateur (INSERT) l'autre pour en supprimer un (DELETE).
A part dans ces deux cas, toutes mes requêtes fonctionnent en utilisant query().
J'ai vu que dans certains cas on pouvait être sujet à l'injection SQL , j'ai pas trop compris comment ça marche.
il y a d'autres façons de se protéger, mais c'est plus simple avec prepare/execute.
cela me semble donc une bonne pratique, tout en sachant qu'il faut continuer à se protéger contre d'autres attaques que l'injection SQL