Discussion :

[ABCIWEB]

@clickandgo

Donc si ta requête ne fonctionne pas à cause de la double utilisation de :displayName (conjointement à la configuration $pdo_options[PDO::ATTR_EMULATE_PREPARES] = false), il te suffira de faire

Code php :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
$conn = C_PDO::getC();
 
        $sql = "SELECT userName from users 
                                WHERE userName = ?
                                UNION 
                                SELECT bankerName from bankers 
                                WHERE bankerName = ?;
        $result = $conn->prepare($sql);
        $result->execute([$displayName,$displayName]);

A mon avis c'est mieux de laisser ATTR_EMULATE_PREPARES = false pour laisser fonctionner l'émulateur propre au serveur de base de donnée plutôt que d'utiliser l'émulateur générique de php. Les avantages sont globalement supérieurs aux inconvénients, cf ce sujet par exemple et concernant ce problème de double utilisation d'un même placeholder, tu pourras toujours contourner facilement ce problème.

[CosmoKnacki]

Ou encore d'utiliser deux placeholders au lieu d'un.

Une autre option serait d'éviter l'union dans la requête en modélisant la base de données autrement, avec tous les utilisateurs (banquier ou non) dans la même table, et où la table banker se contenterait d'une clef étrangère (l'id de la table user) pour savoir qui est banquier et qui ne l'est pas.

[ABCIWEB]

D'après ce que j'en ai compris (en mode PDO::ATTR_EMULATE_PREPARE à true):

• si tu utilises PDOStatement::bindValue avec PDO::PARAM_INT et en veillant à ce que la valeur soit bien de type int, tout va bien.
• par contre PDOStatement::execute() avec un tableau associatif, il semblerait que tu puisses oublier.

À vérifier.

Oui mais alors non, se passer de pouvoir envoyer un tableau dans le execute, c'est se passer d'une fonctionnalité pratique essentielle de pdo... (en plus du côté moins verbeux et plus universel c'est aussi un gros avantage par rapport à mysqli). Par ailleurs dans un code sécurisé on contrôle toujours les variables à réception du post (ce qui permet aussi d'envoyer des messages d''erreur personnalisés), de sorte qu'un bind individuel des variables pour indiquer leur type dans la requête est inutile.

Cela fait très longtemps (quasiment depuis que j'utilise pdo) que je configure PDO::ATTR_EMULATE_PREPARE = false, et cela ne m'a jamais posé de problèmes. En fait je ne me suis jamais trouvé dans le cas de figure que tu décris, mais quand bien même c'est très facilement contournable. Après je ne dis pas que mon expérience regroupe tous les cas de figure mais pour mon utilisation généraliste c'est la bonne configuration.

Concernant ton dernier message, oui évidemment on pourrait utiliser deux placeholders au lieu d'un, mais comme tu l'as peut-être compris je n'utilise des placeholder que lorsqu'ils sont indispensables et c'est rarement le cas, donc je voulais montrer à clickandgo une utilisation basique avec les marqueurs et un tableau (tout aussi basique) dans le execute.

@clickandgo Après évidemment les placeholders sont pratiques (y compris quand on passe un tableau dans le exécute) lorsqu'il est difficile d'ordonner les éléments du tableau dans le même ordre que les marqueurs, ou pour une meilleure lisibilité lorsque les paramètres sont très nombreux, mais à mon avis il est important de maitriser également la syntaxe avec marqueurs (?) car elle est très pratique.
Enfin, si quelque chose ne fonctionne pas, n'oublies pas de nous indiquer le message d'erreur retourné par php.

[laurentSc]

pour une meilleure lisibilité

C'est la raison pour laquelle j'utilise systématiquement des placeholders. Va relire un vieux code qui n'utilise que des marqueurs non marqués...

[ABCIWEB]

C'est la raison pour laquelle j'utilise systématiquement des placeholders. Va relire un vieux code qui n'utilise que des marqueurs non marqués...

Bah c'est ce que je fais tous les jours et si cela me posait des problèmes j'utiliserais des placeholders. Les deux méthodes existent, c'est pas pour rien. Dans une requête classique tu as les points d'interrogation en regard des champs, et la ligne du dessous tu as tes variables dans un tableau. Bref tu as tout sous la main pour avoir une vision claire du code. Regarder si le troisième point d'interrogation correspond au troisième élément du tableau c'est pas sorcier. Il n'y a que dans des requêtes avec une écriture complexe que les placehoders se justifient.