neo_corps

Bonjour à tous,

Comme dit dans le titre, je travaille avec une version 2.6.0-rc2 de phpmyadmin chez un hébergeur. La version php est la 5.
Avant d'etre chez cet hébergeur j'etais chez 1and1 avec phpmyadmin version 2.6.4-pl3

Voilà donc mon probleme :

lors d'une exécution tout bete d'une requete upadte :


je suis obliger de rajouter des "" pour encadre ma variable $contenu sinon j'ai des retour d'erreur sql. La requete ci-dessus est celle chez 1and1 et voilà celle que je suis obligé de mettre chez mon hébergeur local :



Le probleme est que si dans ma variable on retrouve un caractère " et bien ca fout le souk et elle ne passe plus. J'aurai bien aimer pouvoir rajouter simplement des ' au lieu des " mais apres j'ai des erreurs php.

Quelqu'un pourrait-il me sortir de là (et éviter de me dire que mon hébergeur doit changer de version de phpmyadmin).

Merci bien ;)

zebden

Lu,

tout ca n'a rien à voir avec phpmyadmin, une chaine proprement dite doit être délimitée pour l'assimiler comme telle. Si dans ta chaine, tu as un guillemet, logiquement ca entraine la fin de la chaine.

Donc pour parer ce probleme :

contenu_generalites="'. mysql_real_escape_string($contenu) . '"

Cette fonction a pour but d'echapper les caractères spéciaux et de preparer l'insertion dans une base Mysql. En revanche une chaine de type INT, n'a pas besoin d'être délimitée, entrainant même chez certaines bdd, une erreur.

neo_corps

Merci je vais tester ca, on m'a soumis d'autre solution mais c'était les ' qui bloquait et plus les ".

J'ai assimilé ce probleme a la version car avec la version de 1and1 il n'y avait aucun probleme. C'est venu depuis le changement d'hébergeur.

neo_corps

Voila differentes manières avec lesquelles mon problème s'est résolu.



et



Merci bien !!!!

zebden

Je vais t'expliquer pourquoi ca marchait avant, 1and1 a les magic_quotes d'activé, c'est à dire que ca remplace(ca echappe automatiquement) :

$sql = "UPDATE historique SET contenu='".addslashes($contenu)."' WHERE id_historique='".$id."'";

ce qui ne protège pas forcement. Mieux vaut utiliser mysql_real_escape_string.