Signification de cette requête bizarre

Bonsoir,

je suis en train de reprendre un code de quelqu'un d'autre et je me demande la signification d'une telle requête :

Code:

---

INSERT INTO infoappli () VALUES (:ch)

---

Il s'agit d'une requête préparée d'où le :ch. Ce que je ne comprends pas ce sont les 2 parenthèses derrière le nom de la table infoappli ; peut-on m'expliquer ?

Quelle est la base de données ?

MySQL et en fait, je l'interroge via du PHP/PDO.

Cette requête fonctionne-t-elle ? Si oui, c'est probablement une spécificité de MySQL.

Quoi qu'il en soit, il n'est pas recommandé de faire un insert sans mentionner explicitement les colonnes : si le DDL évolue, il est peu probable (je préfère être prudent car je ne connais pas MySQL) que la requête continue de fonctionner.

À remplacer avantageusement par :

Code:

---

insert into TableName (col1, col2, col3....) values (:val1, :val2, :val3...)

---

Je comprends pourquoi ils ont essayé de simplifier : il y a 19 colonnes !
Cela dit, j'ai fait un essai en modifiant seulement 2 colonnes et il n'y a plus d'erreur !
Pour info, la requête actuelle est (avec le code PHP) :

Code:

---

1 2 3 4 5 6

$query_infoappli = "INSERT INTO infoappli (name, ansys) VALUES (:name,:ansys)"; $qid=$bdd->prepare($query_infoappli); $qid->bindParam(':name',$insname); $qid->bindParam(':ansys',$insappli[0]); $qid->execute();

---

Par contre, j'ai une autre erreur (sur la ligne 6 alors qu'avant c'était sur la ligne 3) :

Citation:

---

Uncaught exception 'PDOException' with message 'SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'OLDr-98-fr' for key 'PRIMARY'' in D:\wamp\www\devjupiter\pdo\page\modifier.htm on line 190

---

(la ligne 190 correspond ici à la ligne 6)
Le message me dit que je duplique une clé primaire, mais un insert ne fait que créer un nouvel enregistrement donc où est la duplication ?

Vu la rareté des réponses, un modo pourrait-il déplacer cette discussion dans http://www.developpez.net/forums/f825/php/php-sgbd/pdo/ ?

Citation:

---

Envoyé par laurentSc

Vu la rareté des réponses, un modo pourrait-il déplacer cette discussion dans http://www.developpez.net/forums/f825/php/php-sgbd/pdo/ ?

---

Bonjour,

cela serait en effet possible mais en fait la rareté des réponses est plus due à une lacune d'informations qu'autre chose
1- le premier pos, sans info sur le SGBD, on a INSERT INTO infoappli () VALUES (:ch) ce qui tendrait à faire penser que la table infoappli n'a qu'un seul champ , requête bizarre mais MySQL est tellement "bizarre" lui aussi que cela pourrait passer
2- ensuite on se retrouve avec INSERT INTO infoappli (name, ansys) VALUES (:name,:ansys), une instruction SQL tout-à-fait correcte, mais là on apprend que la table contient en fait 19 champs et vous nous posez une question sur un problème de clé, ce qui somme toute est tout-à-fait possible ; il faudrait vérifier les données de votre table avant d'incriminer le SQL.

Bref, avant de parler de rareté des réponses (alors que vous en avez quand même obtenu de la part d'escartefigue), posez d'abord clairement votre problème (lisez les règles du forum langage sql), et n'oubliez pas : une discussion = une question.

Maintenant, si vous voulez toujours transférer cette discussion, (et si ce n'est déjà fait) passez moi un petit mp et je ferai ça lors d'une de mes nombreuses heures de libre du W.E. :mouarf:

Je vais essayer de combler ce manque d'information, mais dans la limite de mes connaissances.

Tout d'abord, le fait de faire croire qu'il n'y a qu'une seule colonne n'est pas dû au code récupéré, mais à moi ! La requête n'était pas préparée (d'ailleurs, impossible vu que PDO n'était pas utilisé, c'était les fonctions mysql_xxx) et que ayant mal corrigé, j'avais remplacé les 19 colonnes par une seule...

Sinon, je n'incrimine pas, mais seulement, ne comprends pas. Pour essayer d'éclaircir, je viens de faire un export dans phpMyAdmin, ce qui me donne la structure de la table :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

CREATE TABLE IF NOT EXISTS `infoappli` ( `name` varchar(20) COLLATE latin1_bin NOT NULL DEFAULT '', `ansys` tinyint(4) DEFAULT NULL, `autre` tinyint(4) DEFAULT NULL, `cadence` tinyint(4) DEFAULT NULL, `cadra` tinyint(4) DEFAULT NULL, `fluent` tinyint(4) DEFAULT NULL, `medusa` tinyint(4) DEFAULT NULL, `mentor` tinyint(4) DEFAULT NULL, `metaphase` tinyint(4) DEFAULT NULL, `moldflow` tinyint(4) DEFAULT NULL, `pcnetlink` tinyint(4) DEFAULT NULL, `proengineer` tinyint(4) DEFAULT NULL, `prointralink` tinyint(4) DEFAULT NULL, `promecanica` tinyint(4) DEFAULT NULL, `propdm` tinyint(4) DEFAULT NULL, `samba` tinyint(4) DEFAULT NULL, `ssh` tinyint(4) DEFAULT NULL, `symphony` tinyint(4) DEFAULT NULL, `visula` tinyint(4) DEFAULT NULL, PRIMARY KEY (`name`), UNIQUE KEY `name` (`name`) ) ENGINE=MyISAM DEFAULT CHARSET=latin1 COLLATE=latin1_bin;

---

Il y a bien une clé primaire sur la colonne "name" qui est celle de la donnée citée dans le message d'erreur, sauf que dans le cas d'un insert, je ne vois pas comment on peut dupliquer...

Re,

Citation:

---

Envoyé par laurentSc

il y a bien une clé primaire sur la colonne "name" qui est celle de la donnée citée dans le message d'erreur, sauf que dans le cas d'un insert, je ne vois pas comment on peut dupliquer...

---

Un INSERT ne contrôle pas si la clé existe, c'est lors de l'exécution du SQL que l'erreur est levée : si la clé existe alors l'erreur est une violation de contrainte (une clé primaire étant également unique) et donc de clé en double (duplicate entry) , la table eut été vide l'erreur n'aurait pas été levée. Si ma lecture de l'erreur est bonne (je ne suis pas un mySQL user) vous avez tenté d'insérer un enregistrement avec pour la valeur de name 'OLDr-98-fr' , enregistrement déjà existant dans la table.

Bonne lecture car effectivement, là, j'aurais dû faire un update et pas un insert ; si ça s'était bien passé, ça aurait été le cas, mais le comptage des lignes de la table a échoué : le bug est là, mais je ne le comprends pas (et donc ne vois pas la solution) :

Code:

---

1 2 3 4 5

$query_init = "SELECT * FROM `infoappli` WHERE name=:name"; $qid=$bdd->prepare($query_init); $qid->execute(array(':name'=>'"'.$insname.'"')); $nrows=0; while( $row=$qid->fetch(pdo::FETCH_ASSOC) ) $nrows++;

---

La requête SQL effectuée est une requête préparée avec marqueur nommé et qui prend la valeur "DBMAP" (c'est un autre essai, donc le nom a changé).

J'ai pu corriger le problème sachant que le nombre de lignes est forcément supérieur à zéro vu que ce fichier n'est appelé que pour modifier un enregistrement que l'on vient de sélectionner, donc j'ai supprimé le test (comprends pas pourquoi il était fait) mais je ne cocherai "résolu" que quand j'aurai compris pourquoi la lecture du nombre de lignes échouait ; et au passage, je sais aussi qu'on aurait pu le faire avec un count(*) sauf que je n'y arrive pas :

Code:

---

1 2 3 4 5 6

$query_init = "SELECT count(*) FROM `infoappli` WHERE name=:name"; $qid=$bdd->prepare($query_init); $qid->execute(array(':name'=>'"'.$insname.'"')); $row=$qid->fetch(pdo::FETCH_ASSOC); var_dump($row);

---

Merci d'avoir déplacé ma discussion, mais entre temps, dans le cadre d'une autre discussion, j'ai su comment compter les lignes retournées par un SELECT :

Code:

---

1 2 3 4 5 6 7

$query_init = "SELECT COUNT(*) AS compte FROM `infoappli` WHERE name=:name"; $qid=$bdd->prepare($query_init); $qid->execute(array(':name'=>$insname)); $row=$qid->fetch(pdo::FETCH_OBJ);   $nrows=$row->compte;

---