Vous n'êtes pas identifié(e).
Bonjour à tous.
Voilà, je suis passée récemment de la 8.2 à la 8.3 sur un serveur Windows 2003.
Mon soucis c'est que depuis cette mise à jour du serveur PostgreSQL, je ne peux plus créer de Bases de données, ni donc restaurer des Bases de données en LATIN9 ? Mais obligée de choisir UTF8 ou WIN1252.
Alors que l'application que nous a livré le prestataire fonctionne sur une BDD en latin9.
Que puis-je faire? je souhaite absolument restaurer mes BDD en LATIN9. Dois-je réinstaller PostgreSQL ou y-a-t il un paramètre dans un fichier de configuration qui me permettrait d'y remédier?
Merci d'avance.
Cordialement.
Hors ligne
Avec PostgreSQL, il y a gestion de deux encodages, celui de stockage (server_encoding) et celui de discussion entre le serveur et le client (client_encoding).
Dans votre cas, vous créez votre base en UTF-8 ou en WIN1252, et vous pourrez restaurer votre sauvegarde en LATIN9 (il y a plus de chances que la conversion fonctionne vers de l'UTF-8). Ensuite, pour la discussion entre l'application et le serveur, vous pouvez faire en sorte que la communication se fasse toujours en LATIN9 en modifiant la configuration de la base de données :
ALTER DATABASE votre_base SET client_encoding TO latin9;Guillaume.
Hors ligne
Merci pour cette réponse.
J'ai restaurer ma base de données mais elle est encodé au niveau serveur en UTF-8. Ensuite j'ai modifié le paramètre client_encoding de cette base de données pour la mettre en LATIN9.
A priori tout fonctionne.
Mais je me pose la question quand même, pourquoi l'encodage du serveur ne peut être initialisé à LATIN9 si on peut paramétrer la conversation client/BDD en LATIN9 ?
Est-ce que ma base de données est toujours intégre en passant de LATIN9 à UTF-8 ?
Cordialement.
Hors ligne
Parce que le cluster a été initialisé avec un algo de tri alphabétique (collate ou collation) incompatible avec le LATIN9. Jusqu'à la version 8.3, ce collate est global au cluster. Depuis la 8.4, on peut avoir un collate différent par base.
Marc.
Hors ligne
Bonjour.
Cette réponse me va. En gros, je passerai dès que possible mon serveur à la 8.4 puisque mes bases de données sont encodées différemment.
Bonne journée à tous.
Hors ligne
Bonjour,
je suis toujours bloqué, sur le même type de problème.
J'ai migré une application d'une machine Linux (avec PostgreSQL 8.3.0) vers une machine Windows (avec PostgreSQL 9.1.4)
J'aimerais que les select sur les champs "date" en base de données me renvoient des dates au format "DD/MM/YYYY" comme c'était le cas sur l'ancienne machine. Mais je n'y arrive pas.
================ SUR L'ANCIENNE MACHINE =========================
dtidb=# show client_encoding;
client_encoding
-----------------
LATIN9
(1 row)
dtidb=#
dtidb=# show server_encoding;
server_encoding
-----------------
LATIN9
(1 row)
dtidb=# select dateorder from orders where id = 2053;
dateorder
------------
12/12/2007
(1 row)
=========== SUR LA NOUVELLE MACHINE =============================
dtidb_backup=# show client_encoding;
client_encoding
-----------------
WIN1252
(1 row)
dtidb_backup=# show server_encoding;
server_encoding
-----------------
UTF8
(1 row)
dtidb_backup=# select dateorder from orders where id = 2053;
dateorder
------------
2007-12-12
(1 row)
========================================
Que dois-je faire pour avoir la date au format DD/MM/YYYY ?
Merci d'avance pour votre aide !
Dernière modification par Hermann (17/09/2012 16:23:38)
Hors ligne
J'ai exécuté :
ALTER DATABASE test SET client_encoding TO 'LATIN9';
Mais ça n'a rien changé sur l'affichage de la date (le select) ...
Hors ligne
Essayez DateStyle (http://docs.postgresql.fr/9.2/runtime-c … -datestyle).
Et la prochaine fois, créez un nouveau fil de discussion pour une nouvelle question.
Guillaume.
Hors ligne
Merci pour votre message.
J'ai déjà mis datestyle = 'iso, dmy' dans postgresql.conf
J'ai observé que ce paramètre était utilisé par postgresql lors de l'enregistrement d'une donnée de type date.
Mais visiblement il n'est pas utilisé lors de la lecture (select dans la base) ?
Hors ligne
L'affichage d'un timestamp ou d'un date est toujours en YYYY-MM-DD. Si vous voulez autre chose, il faut utiliser la fonction to_char.
Guillaume.
Hors ligne
Bonjour,
Merci pour votre retour.
Mais j'ai dû passer au plan B : Modifier les sources PHP de l'application, afin de prendre en compte le fomat YYYY-MM-DD au lieu de DD/MM/YYYY.
A bientôt,
Hors ligne