# Parcours anormal d'un tableau au retour d'une requête SQL (avec un UNION) **URL:** \ **Category:** Programmation\ **Created:** [Novembre 7, 2020, 12:54 UTC](https://www.debian-fr.org/t/parcours-anormal-dun-tableau-au-retour-dune-requete-sql-avec-un-union/83205 "2020-11-07T12:54:27Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![jhfra](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/j/eb9ed0/32.png) [@jhfra](https://www.debian-fr.org/u/jhfra)\ **Post date:** [Novembre 7, 2020, 12:54 UTC](https://www.debian-fr.org/t/parcours-anormal-dun-tableau-au-retour-dune-requete-sql-avec-un-union/83205/1 "2020-11-07T12:54:27Z")
Hello, Mon objectif : réaliser un comptage de résultat sur un table qui contient les résultats d’un sondage. Lorsqu’un votant met « oui », je renseigne pour son résultat un 0 et lorsqu’il met « non », je renseigne un 1. Voici le code : ``` $query = $GLOBALS['pdo']->prepare(" SELECT COUNT(vote_id) as nbr0 FROM votes_votants WHERE vote_votes_id = :vote_id1 AND vote_choix='0' UNION SELECT COUNT(vote_id) as nbr1 FROM votes_votants WHERE vote_votes_id = :vote_id2 AND vote_choix='1'"); $query->bindValue(':vote_id1',$vote_id,PDO::PARAM_INT); $query->bindValue(':vote_id2',$vote_id,PDO::PARAM_INT); $query->execute(); while ($datas = $query->fetch()) { $nbr0 = $datas['nbr0']; $nbr1 = $datas['nbr1']; } ``` La requête, elle même prise indépendamment du code me renvoie 2 lignes : > 4 > 9 Donc **$nbr0** devrait valoir 4 et **$nbr1** valoir 9. Maintenant, mon code PHP me renvoie ceci : > 9 - Première anomalie : je n’ai qu’un résultat, alors que j’ai pourtant 2 lignes attendues.. - Deuxième anomalie : Pourquoi 9 et pas 4 ? Comme si le résultat de nbr1 écrasait le résultat de nbr0 J’ai modifié mon code pour parcourir mon tableau différemment (à coup de fetchall et foreach), même résultat. Puis j’ai également utilisé les index des tableaux plutôt que les noms pour ressortir mes valeurs, même résultat aussi. Là je sèche complètement. Pouvez-vous m’aider ? ---
**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\ **Post date:** [Novembre 7, 2020, 1:00 UTC](https://www.debian-fr.org/t/parcours-anormal-dun-tableau-au-retour-dune-requete-sql-avec-un-union/83205/2 "2020-11-07T13:00:45Z")
quelle est la structure de ta table? Pourquoi faire un union, ce n’est pas utile: `select vote_id, count(vote_id) from votes_votans group by vote_id;` ---
**Author:** ![jhfra](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/j/eb9ed0/32.png) [@jhfra](https://www.debian-fr.org/u/jhfra)\ **Post date:** [Novembre 7, 2020, 1:31 UTC](https://www.debian-fr.org/t/parcours-anormal-dun-tableau-au-retour-dune-requete-sql-avec-un-union/83205/3 "2020-11-07T13:31:33Z")
merci pour ton aide ! Pour la structure : |#|Nom|Type|Interclassement|Attributs|Null|Valeur par défaut|Commentaires|Extra| |1| **vote\_id** |int(9)|||Non|_Aucun(e)_||AUTO\_INCREMENT| |2| **vote\_votes\_id** |int(9)|||Non|_Aucun(e)_||| |3| **vote\_matricule** |int(6)|||Non|_Aucun(e)_||| |4| **vote\_choix** |tinyint(1)|||Non|_Aucun(e)_||| |5| **vote\_heure** |datetime|||Non|current\_timestamp()||| J’ai une autre table qui contient la référence du sondage (avec le sujet, et d’autre paramètres). Donc là je prends tous les résultats correspondant au **vote\_votes\_id** (l’id de mon sondage) et je veux avoir le nombres de **vote\_choix** à 0 et ceux à 1. Pour info, avec ton correctif ça donne chez moi : ``` SELECT COUNT(vote_id) FROM votes_votants WHERE vote_votes_id = 133 GROUP BY vote_choix ``` (où 133 est l’id d’un sondage) Ton optimisation est donc la bonne approche côté SQL, j’ai modifié mon code, mais ça ne corrige pas mon problème d’origine. Je ne comprends pas pourquoi on ne dépasse pas la première ligne et pourquoi cette première ligne prend le résultat de la seconde. ---
**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\ **Post date:** [Novembre 7, 2020, 2:11 UTC](https://www.debian-fr.org/t/parcours-anormal-dun-tableau-au-retour-dune-requete-sql-avec-un-union/83205/4 "2020-11-07T14:11:17Z")
C’est parce que tu n’a pas pris la requête correctement: vote\_id correspond au vote choisi, et vote\_choix le oui ou non? dans ce cas la requête est plutôt: `select vote_choix, count(vote_choix) from votes_votans where vote_id=133 groupe by vote_choix` Tu comptes les oui et les nom pour le vote numéro 133. Pour compter pour tous les votes: `select vote-id,vote_choix, count(vote_choix) from votes_votans where vote_id=133 groupe by vote-id,vote_choix` ---
**Author:** ![jhfra](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/j/eb9ed0/32.png) [@jhfra](https://www.debian-fr.org/u/jhfra)\ **Post date:** [Novembre 9, 2020, 8:16 UTC](https://www.debian-fr.org/t/parcours-anormal-dun-tableau-au-retour-dune-requete-sql-avec-un-union/83205/5 "2020-11-09T08:16:48Z")
Hello, oui, c’est bien ça, mais dans ce cas je traite commence résultat avec PHP ? ---
**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\ **Post date:** [Novembre 9, 2020, 8:51 UTC](https://www.debian-fr.org/t/parcours-anormal-dun-tableau-au-retour-dune-requete-sql-avec-un-union/83205/6 "2020-11-09T08:51:20Z")
Le resultat final de ta requête se retrouve dans un fetch, avec 3 champs si tu couvre tous les votes, 2 champs si tu couvre un vote particulier dans la clause where sur le champ vote\_id. Le premier tuple sera les votes 0 le deuxième les votes 1 (suivant la valeur du champ vote\_choix). ---
**Author:** ![jhfra](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/j/eb9ed0/32.png) [@jhfra](https://www.debian-fr.org/u/jhfra)\ **Post date:** [Novembre 9, 2020, 9:12 UTC](https://www.debian-fr.org/t/parcours-anormal-dun-tableau-au-retour-dune-requete-sql-avec-un-union/83205/7 "2020-11-09T09:12:39Z")
> [@Zargos](#): > > select vote\_choix, count(vote\_choix) from votes\_votans where vote\_id=133 groupe by vote\_choix Ok, je viens de comprendre.. je commençais au mauvais endroit ! Mille mercis !