PDO insert into

FIXED : Probleme de virgule dans ma requete

Bonjours j'ai un probleme d'insertion de valeurs vers ma BDD....

ma table :
Pièce jointe 628230


dans ma function addBuilding en parametre $infos est un tableau et [edificeid] est vide j'ai fait en sorte qui soit NULL mais cela semble causer probleme.... est-ce que je me trompe ?

$infos
(
[edificeid] =>
[nom_du_lieu] => MontrealCPI
[numero] => 458
[rue] => aaa
[ville] => d
[province] => Quebec
[pays] => d
[codePostal] => aaa
[actif] => no
[memberid] => 46
)


voici la function

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

[PHP] function addBuilding($pdo,$infos) {   try { $sql = "INSERT INTO TFSPCC__edifice (edificeid, nom_du_lieu, numero, rue, ville, province, pays, codePostal, actif, memberid) VALUE (:edificeid , :nom_du_lieu, :numero, :rue, :ville, :province, :pays, :codePostal, :actif :memberid)";   $stmt= $pdo->prepare($sql);   $stmt->execute($infos);   } catch (Exception $e) { die( $e. "error SQL"); } }; [/PHP]

---

je recois toujour cette erreur
PDOException: SQLSTATE[21S01]: Insert value list does not match column list: 1136 Column count doesn't match value count at row 1 /La liste de valeurs d'insertion ne correspond pas à la liste de colonnes



Si j'écris mon code de cette facon cela passe numero 1.... mais clairement que je ne veux pas passer par cette procedure c'est beaucoup trop long de tout écrire dans les values.

Code:

---

1 2 3 4 5

[PHP] $sql = "INSERT INTO `TFSPCC__edifice` (`edificeid`, `nom_du_lieu`, `numero`, `rue`, `ville`, `province`, `pays`, `codePostal`, `actif`, `memberid`) VALUES (NULL, 'd', 'd', 'd', 'd', 'd', 'd', 'd', 'no', '46');"; $stmt= $pdo->prepare($sql); $stmt->execute(); [/PHP]

---

Si jamais tu es sous MySQL, tu peux utiliser la syntaxe alternative du INSERT qui reprend celle du UPDATE et qui est beaucoup plus lisible quand le nombre de colonnes augmente.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

$sql = <<<SQL   INSERT INTO TFSPCC__edifice   SET   edificeid = :edificeid,   nom_du_lieu = :nom_du_lieu,   numero = :numero,   rue = :rue,   ville = :ville,   province = :province,   pays = :pays,   codePostal = :codePostal,   actif = :actif,   memberid = :membreid   SQL;

---

Je ne savais même pas que je pouvais faire cela, c'est clairement plus lisible merci de l'information.

Par ailleurs, tu mets tous tes champs "not nullable". Je pense que c'est une erreur.
Il y a des adresses sans numéro ni rue (un hameau), et sans province.Es-tu bien sûr que tes utilisateurs résideront toujours au Québec ?
Bref, il faut faire des adresses infiniment plus souples.
Il manque également le champ "complement" pour les grandes résidences, il y a toujours un complément d'adresse.
Personnellement, je ferais

adresse, complement, codePostal, ville, province, pays (tout en nullable sauf ville et pays)

Je ne suis pas du tout d'accord.

Tout d'abord, ces colonnes (et non pas "champs") devraient bien rester "not null" sous réserve que la base de données soit bien modélisée, ce qui est loin d'être le cas ici. En effet, pour tous les édifices présents dans une même ville, on devra ressaisir la ville avec des risques d'incohérences orthographiques. Même chose pour les codes postaux, les rues, etc.
Les colonnes "nullables" sont l'exception dans une base de données bien construite.
Il faudrait donc avoir plusieurs tables liées par des FK pour les villes, les codes postaux, les édifices...
Dans l'unique table, on trouve en PK l'édifice et en FK le membre ça signifie qu'un édifice est associé à un et un seul membre.
Je serai curieux de connaître les règles de gestion ayant conduit à ce choix.

Ensuite, les adresses françaises comme étrangères sont normées par la poste. Suivre cette norme est recommandé pour éviter les adresses incomplètes ou non utilisables. Cette norme est accessible gratuitement sur le web. Si on met tout en "nullable" on a éventuellement un code postal marqué "null" et une ville marquée "null", donc une adresse inutilisable !

Enfin, le typage des données est une chose importante. Il ne faut pas utiliser systématiquement du varchar.
Par exemple :

• la notion d'"actif" est probablement à remplacer par un booléen ;
• le code postal, s'il s'agit d'une adresse française, se code sur 5 caractères. Du char(5) fixe sera donc plus performant que du varchar ;
• le numéro dans la rue devrait aussi être stocké dans du char fixe court, par exemple char(5) devrait suffire largement ;
• le nom de la ville et de la rue doivent être stockés dans du varchar(38). Cf. là encore la norme de la poste.