Vous n'êtes pas identifié(e).
Bonjour,
comme dit dans le titre : jusqu'à vendredi, ça marchait bien et depuis, si l'affichage (via phppgadmin par exemple) est toujours correct, les requêtes ne fonctionnent plus !
Si qqun a une idée sur pourquoi ça a pu se mettre à dysfonctionner d'un seul coup et comment revenir à l'état antérieur, je suis preneur.
merci d'avance
en fait, en ligne, ça marche.
Ce n'est que via PhpPgAdmin que les accents ne sont plus reconnus.
L'encodage à dû sauter : pourquoi, le mystère reste entier.
Donc, la question devient : peut-on facilement gérer l'encodage en ligne de commande d'une base postgres (celle-ci est en ASCII-SQL)
Dernière modification par Didier Bétored (08/03/2010 11:05:10)
Hors ligne
Il serait intéressant de founir une requête qui fonctionnait mais ne fonctionne plus, ainsi que le message d'erreur.
Avez-vous changer la locale du serveur PostgreSQL et/ou du serveur disposant de phpPgAdmin ?
Guillaume.
Hors ligne
pas d'erreur : un simple select sur 'congés' renvoyait les lignes concernées et maintenant dit "pas de résultat" via PhpPgAdmin et les bonnes lignes via la ligne de commande de psql
A priori, on n'a touché à rien mais sur un serveur c'est dur d'être sûr ...
Dernière modification par Didier Bétored (08/03/2010 11:14:48)
Hors ligne
Pouvez vous tout de même fournir la requête ?
Et nous dire ce que valent server_encoding et client_encoding dans votre session ?
Dernière modification par Marc Cousin (08/03/2010 11:54:53)
Marc.
Hors ligne
Bon, on a trouvé une correction manuelle et on sait pourquoi :
Suite à une erreur, j'ai effacé la base, pris le dump en ascii et refait la base.
Lors de cette manip l'encodage a changé les 'é' et autres 'è' en diverses cochoneries dans les requêtes des vues alors que ça restait de braves 'e' accentués dans la base donc les selects ne trouvaient rien de correspondant.
Nous avons corrigé les requêtes à la main en fixant l'encodage du navigateur où nous faisons tourner PhpPgAdmin (ISO-8859-15) et tout est rentré dans l'ordre.
Mais n'y aurait-il pas moyen de graver les encodages dans le marbre afin d'éviter que ça se reproduise à chaque restauration de base (même sans faire des erreurs tous les jours, on n'est pas à l'abri ....)
De toutes façons : merci de vos réponses rapides 
Dernière modification par Didier Bétored (08/03/2010 12:42:15)
Hors ligne
Et nous dire ce que valent server_encoding et client_encoding dans votre session ?
et pour ça : je ne sais pas vraiment comment récupèrer ces infos facilement ...
J'ai regardé la doc et pourrais peut-être en inscluant la requête dans la page PHP mais simplement, je ne vois pas ...
Hors ligne
Mais n'y aurait-il pas moyen de graver les encodages dans le marbre afin d'éviter que ça se reproduise à chaque restauration de base (même sans faire des erreurs tous les jours, on n'est pas à l'abri ....)
Oui, c'est possible et même recommandé... mais dans ce cas, il ne faut pas utiliser SQL_ASCII. Ce pseudo-encodage indique tout simplement que vous ne vous intéressez pas à l'encodage de vos données (ie, PostgreSQL ne vérifie pas si l'encodage est bon).
Guillaume.
Hors ligne
OK merci
ça nous semblait souple ... et ça l'est le plus souvent quand il n'y a pas de pb.
Simplement on ne maîtrise rien en fait.
Mais est-ce envisageable de "recoder" des bases existantes ou est-ce que c'est trop tard (je n'ai pas trop envie de casser des choses qui, sauf accident, ne tournent pas trop mal ?
Hors ligne
C'est très souple et très pratique vu que PostgreSQL ne vous refusera rien dans un champ texte (en dehors de données binaires comme 0x00). Par contre, en effet, vous pouvez insérer du LATIN9, de l'UTF-8 et d'autres encodages, ce qui peut poser des problèmes majeurs à la lecture et surtout à la restauration dans une base non SQL_ASCII car cette dernière ne supportera pas deux encodages différents et vous le fera savoir en refusant d'intégrer certaines données.
Bref, pour vous en sortir, il vous faut une instance initialisée avec un encodage autre que SQL_ASCII et y restaurer votre base. Pour cela, vous pouvez vous aider de différents documents:
* deux billet de mon blog : http://blog.guillaume.lelarge.info/inde … -que-UTF-8 et http://blog.guillaume.lelarge.info/inde … d-encodage
* deux billets de Dimitri Fontaine : http://blog.tapoueh.org/articles/blog/_ … art_1.html et http://blog.tapoueh.org/articles/blog/_ … art_2.html
Guillaume.
Hors ligne
Hé bien merci pour tout: je vais tenter de rendre tout ça plus "propre" avec cette aide ...
À la prochaine
Didier
Hors ligne
