Quelle paramètre doit on changer pour voir la requete complète dans les traces ?
Bon, j'ai toujour pas trouvé la raison de ce dysfonctionnement... Je continue de creuser, mais ça commence a me gaver xD
]]>Pour la 9.2, si elle est démarrée, elle doit écouter sur un port et/ou une ip différente. Il faut donc spécifier dans la configuration php les informations pour accéder à celle là.
L'ordre d'affectation ne devrait pas avoir d'importance, par contre vu le nombre de paramètre, il est toujours possible d'avoir un décalage entre celui auquel on s'attend et celui réellement utilisé.
]]>j'utilise la version 8.4 (d'ailleurs je ne comprends pas pourquoi, il y a aussi la 9.2 installée mais c'est pas elle qui est utilisée... bref)
je n'arrive pas a lui faire afficher les valeurs dans les logs, juste la requete avec les placeholders...
Et là, j'ai forcé le cast en (int) pour toutes les valeurs entières de mon php (dès fois que...), et nouvelle erreur :
2013-10-25 10:52:29 CEST ERREUR: syntaxe en entrée invalide pour l'entier : « f »
Je n'ai rien qui s'appelle "f", ni dans les colonnes, ni dans les valeurs...
Si j'enlève le cast, je retrouve la même erreur qu'au début
A titre d'info, j'ai testé en codant en dur le bindValue() pour la colonne qui semble poser problème et ça n'a rien changé non plus
$req->bindValue(":pays", "France", PDO::PARAM_STR);
Est-ce que l'ordre de l'affectation des paramètres à une importance (dans mon cas, où les paramètres sont tous nommés) ?
]]>voici le log d'erreur de pgsql, avec la requete dedans
2013-10-24 11:34:47 CEST ERREUR: syntaxe en entrée invalide pour l'entier : « France »
2013-10-24 11:34:47 CEST INSTRUCTION : INSERT INTO testusagers (
profile, nom, prenom, statut, archive, login, passw, civilite, csp, formation, organisme, adresse1, adresse2, CP, ville, commune_provenance, pays,
date_naissance, email, fax, tel_fixe, tel_mob, date_inscription, eid, connaissances, utilisation, equipement, commentaire, mailing, rappel_anniv)
VALUES (
$1, $2, $3, $4, $5, $6, $7, $8, $9, $10, $11, $12, $13, $14, $15, $16, $17,
to_date( $18, 'DD/MM/YYYY'), $19, $20, $21, $22, to_timestamp( $23, 'YYYY-MM-DD HH24:MI:SS'), $24, $25,$26, $27, $28, $29, $30) RETURNING uid;
Comme ça passe par PDO, je suppose que les $1...$30 sont normaux
]]>J'ai un soucis (en fait, plusieurs, mais j'ai réussi a régler les précédents semble t-il), explications :
Je fais remplir un formulaire sur un page web, jusque là rien d'anormal. J'envoie le contenu de ce formulaire par un jQuery : $.post('inc/ajax.php', $('#adduserform').serialize()
Mon php reçois bien tout et fait ce qu'il a à faire
Parmi les champs du formulaire, il y a un champ "Pays" dont le contenu est par défaut "France", une chaîne donc, c'est sûr.
Dans ma table, c'est aussi une chaine (un varchar(64))
Or, quand je fait ma requête pgsql (en utilisant PDO) j'ai l'erreur " " syntaxe en entrée invalide pour l'entier : «France»", ce que je trouve incohérent car je ne comprends pas pourquoi il s'évertue à considérer ce champ comme un entier alors qu'il s'agit d'un texte.
A titre d'information, voici ce que je fais dans le PHP qui génère la requete :
$req = $this->db->prepare($sql);
foreach($this->userdatas as $key => $value)
{
switch (gettype($value)) {
case 'string': $req->bindValue(":$key", "$value", PDO::PARAM_STR); break;
case 'boolean': $req->bindValue(":$key", $value, PDO::PARAM_BOOL); break;
case 'integer': $req->bindValue(":$key", $value, PDO::PARAM_INT); break;
case 'NULL': $req->bindValue(":$key", $value, PDO::PARAM_NULL); break;
default: $req->bindValue(":$key", "$value", PDO::PARAM_STR); break;
}
}
if ($req->execute()) { ............. }
Je ne suis pas certain que la méthode soit la bonne, mais a priori elle est censée faire ce qui est nécessaire (userdatas est un tableau qui contient donc les 30 parametres de la requete)
S'il vous faut d'autres infos, n'hésitez pas à me demander... merci bien
gege
]]>