Difficulté avec PDO

Difficulté avec PDO - PHP - Programmation

Marsh Posté le 26-06-2015 à 09:48:30    

Hello,
 
Je fais suite ici aux questions posées dans la partie SQL du forum (ici), parce qu'il semblerait que je n'arrive pas à faire fonctionner un truc à cause de PHP et/ou de PDO.
 
Pour résumer : j'ai une requête SQL où je compte le nombre de mots communs entre une table temporaire et une table permanente (dans chacune de ces tables, j'ai un UNIQUE sur la colonne mot), et j'utilise ce code :
 

Code :
  1. $qryCondition = $bdd->prepare('SELECT COUNT(*)
  2.  FROM tableA a
  3.  WHERE EXISTS
  4.   (SELECT 1 from TMP_tableB b
  5.   WHERE a.mot = b.mot)'
  6. );
  7. $qryCondition->execute();
  8. $condition = $qryCondition->fetchAll();


J'espérais que $condition me donnerait le nombre de mots communs entre les deux tables, et donc pouvoir l'utiliser comme ça par exemple :
 

Code :
  1. if ($condition == 0) {
  2. //certaines actions
  3. } elseif ($condition > 0) {
  4. //d'autres actions
  5. }


Mais ça ne fonctionne visiblement pas. var_dump($condition); me donne ça à chaque fois (quel que soit le nombre de mots communs entre les deux tables, que ce soit plusieurs, un seul, ou même s'il n'y en a aucun) :
 

Code :
  1. array(1) {
  2.  [0]=> array(2) {
  3.   ["COUNT(*)"]=> string(1) "0"
  4.   [0]=> string(1) "0"
  5.  }
  6. }


 
Du coup je cherche à savoir ce qui ne va pas, sachant que le problème ne vient pas de la requête, je l'ai testée sur phpMyAdmin (cf mon dernier message) et elle a le comportement attendu.
 
Merci d'avance pour votre aide :)

Reply

Marsh Posté le 26-06-2015 à 09:48:30   

Reply

Marsh Posté le 26-06-2015 à 10:30:48    

$condition est un tableau PHP avec tout tes résultats, pas un entier donc il ne sert à rien de le tester == ou > à zero...
 
Ton var_ dump te donne toutes les infos :
$conditions est un array dans la 1ere clé (1 ère ligne renvoyé par ta requête SQL) est un array de 2 valeurs (car fetch all renvoie par défaut les colonnes récupéré avec leur nom et avec leur ordre).
 
Donc ce que tu veux comparer c'est $condition[0][0] ou $condition[0]["COUNT(*)"]


---------------
D3
Reply

Marsh Posté le 26-06-2015 à 11:13:38    

C'est ce que je me suis dit, et j'ai tenté, mais ça ne fonctionne pas non plus (ce qui en est logique, puisque var dump renvoie toujours string(1) "0" pour $condition[0][0] ).
Je me demande si le problème ne vient pas de fetchAll ?

Reply

Marsh Posté le 26-06-2015 à 11:27:48    

Alors tu as effectivement un problème si ta requête renvoie un résultat différent dans phpmyadmin...
 
Tu as essayé de modifier ta requete PDO en php avec ce qui t'a été suggéré dans l'autre discussion ?
 
Une jointure me semble plus approprier qu'une sous requête...


---------------
D3
Reply

Marsh Posté le 26-06-2015 à 12:14:21    

Je viens de tenter avec la jointure :
SELECT COUNT(*)
FROM tableA A
INNER JOIN tableB B ON B.mot = A.mot

 

Et j'obtiens la même chose, var_dump($condition) me donne toujours :
array(1) {
  [0]=> array(2) {
    ["COUNT(*)"]=> string(1) "0"
    [0]=> string(1) "0"
  }
}

 

Et var_dump($condition[0][0]) me donne toujours :
string(1) "0"

Message cité 1 fois
Message édité par saint malo le 26-06-2015 à 12:15:10
Reply

Marsh Posté le 26-06-2015 à 14:13:47    

Y'a un soucis : tu est sur à 100% que cette requête remonte autre chose que 0 dans phpMyAdmin ?


---------------
D3
Reply

Marsh Posté le 26-06-2015 à 17:52:06    

ton var_dump n'est pas bon, envoi lui directement le tableau complet :  
var_dump($condition);

Reply

Marsh Posté le 26-06-2015 à 22:34:17    

mechkurt a écrit :

Y'a un soucis : tu est sur à 100% que cette requête remonte autre chose que 0 dans phpMyAdmin ?


Yes, je confirme, je viens de réessayer, que ce soit avec cette requête
SELECT COUNT(*) FROM tableA A INNER JOIN tableB B ON B.mot = A.mot
ou celle là,
SELECT COUNT(*) FROM tableA a WHERE EXISTS (SELECT 1 from TMP_tableB b WHERE a.mot = b.mot)
Ca fonctionne dans phpMyAdmin et me donne le bon nombre de mots communs entre les deux tables...

 

Déjà, ce que je ne comprends pas, c'est pourquoi la requête me sort un array de deux lignes dans $condition, alors que dans phpMyAdmin ça ne me sort que ça :
COUNT(*)
           2
 
 
 
 

 
caps lock a écrit :

ton var_dump n'est pas bon, envoi lui directement le tableau complet :
var_dump($condition);


Soit j'ai pas compris, soit il y a un malentendu :) :

saint malo a écrit :

[...]
Et j'obtiens la même chose, var_dump($condition) me donne toujours :
array(1) {
  [0]=> array(2) {
    ["COUNT(*)"]=> string(1) "0"
    [0]=> string(1) "0"
  }
}
[...]

Message cité 1 fois
Message édité par saint malo le 26-06-2015 à 22:38:00
Reply

Marsh Posté le 29-06-2015 à 09:35:28    

saint malo a écrit :

Déjà, ce que je ne comprends pas, c'est pourquoi la requête me sort un array de deux lignes dans $condition, alors que dans phpMyAdmin ça ne me sort que ça :
COUNT(*)
           2


J'ai déjà répondu à ca :

mechkurt a écrit :

$conditions est un array dans la 1ere clé (1 ère ligne renvoyé par ta requête SQL) est un array de 2 valeurs (car fetch all renvoie par défaut les colonnes récupéré avec leur nom et avec leur ordre).


Lit la doc, mais pour la faire courte, tu peux acceder à tes valeurs soit par ordre d'arrivée dans ton select, soit par nom de la colonne...
 
Tu as essayé de récupérer les lignes au lieu de faire un COUNT ?
 
 


---------------
D3
Reply

Marsh Posté le 29-06-2015 à 20:02:01    

Du coup j'ai fini par trouver où était le problème : pour une raison que je ne comprends pas, le problème était avec la table temporaire, qui ne fonctionnait pas. Je ne sais pas si elle ne se créait pas ou si le problème était au niveau des insertions, mais un var_dump d'un select sur cette table temporaire me renvoyait toujours du vide. Du coup je pouvais toujours la comparer à ma table permanente, ça ne risquait pas de me renvoyer autre chose que 0 matchs...
 
Du coup pour la remplacer, j'ai créé une table (permanente) dans ma base, que j'utilise à la place. Et ça fonctionne.
 
Je vais m'en contenter pour le moment donc on peut considérer mon problème réglé ;) Après, si quelqu'un a une idée de quelles raisons peuvent expliquer que des opérations qui marchent sur une table permanente ne marchent pas sur une table temporaire, c'est pas essentiel, mais je suis curieux.
 
Merci pour votre aide à tous en tout cas, c'est cool de pouvoir compter sur cette communauté.

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed