Vous n'êtes pas identifié(e).
Bonjour,
Je suis dans une impasse et je n'arrive pas à m'en sortir.
Etat des lieux : Actuellement, j'ai une CentOs 4.7 sur laquelle se trouve un serveur Web + PostgreSQL V7.4
Suite à une migration matérielle, mon OS n'est évidemment plus compatible...
Je réinstalle le tout sur un RedHat 7.4 sur laquelle j'ai une version de PostgreSQL V9.2.13.
Problème, l'ancienne base est codée en SQL_ASCII. J'ai (beaucoup) cherché et j'ai essayé de faire l'initdb en SQL_ASCII, le cliene encounding, mais je tombe toujours sur des erreurs :
Erreur pendant le traitement de la TOC (« PROCESSING TOC »)
could not execute query: ERREUR: l'encodage « SQL_ASCII » ne correspond pas à la locale « fr_FR.UTF-8 »
DÃTAIL : Le paramètre LC_CTYPE choisi nécessite l'encodage « UTF8 ».
suivi de :
pg_restore: [programme d'archivage (db)] Erreur à partir de l'entrée TOC 8390 ; 0 74948800 TABLE DATA tt_2010 sssss
pg_restore: [programme d'archivage (db)] COPY échoué pour la table « tt_2010 » : ERREUR: séquence d'octets invalide pour l'encodage « UTF8 » : 0xe9 0x64 0x2e
J'avoue que je sèche un peu ... j'ai même essayé de remplacer directement dans le dump l'encodage 'SQL_ASCII' par 'UTF8' avec vi/sed... mais j'ai une erreur de drapeau ...
je suis un peu perdu et j'aurais bien besoin d'aide...
Merci
Manu
Hors ligne
Quel commande utilisez-vous pour l'initdb ?
Guillaume.
Hors ligne
Bonjour et merci,
j'ai utilisé cette commande :
initdb --no-locale --encoding=SQL_ASCII
Hors ligne
Ça paraît bon. Quel commande utilisez-vous pour pg_restore ?
Guillaume.
Hors ligne
j'utilise cette commande :
pg_restore -d Microtheque SauvegardeDu29032018 -v 2>> log.log
La à la dernière restauration, moins d'erreurs mais les champs contenant les caractères accentués ne se sont pas chargés.
En dernier recours, je suis en train de remonter une machine avec postgres V7.4, je pensais upgrader cette version jusqu'en 8.1 ou j'ai vu que le pg_dump permet d'utiliser l'option --encoding... je me dis que je pourrais passer en UTF8 comme ça ...
EDIT : j'ai aussi modifié la variable client_encoding à SQL_ASCII pour la dernière restauration
Dernière modification par noblib (04/04/2018 09:24:58)
Hors ligne
Sans voir le dump, ça va être difficile d'aller plus loin. À mon avis, c'est le bon moment pour corriger les données dans la version 7.4 pour que cette base soit restaurable sur une base UTF-8.
Rien à voir mais je ne vois pas pourquoi vous restaurez en 9.2, version qui n'est plus maintenue par la communauté. Pourquoi ne pas utiliser la dernière qui vous assure de 5 ans de correctifs ?
Guillaume.
Hors ligne
C'est la version de postgres qui est par défaut sur ma version RedHat 7.4... j'ai vu en effet qu'elle était déjà obsolète ...
je vais voir pour obtenir une version plus récente car je suis complètement d'accord avec vous concernant les correctifs.
Du coup je me lance sur mes corrections de données...
encore merci à vous d'avoir pris le temps d'essayer de trouver une solution.
Cordialement
Hors ligne
A propos de cette erreur
ERREUR: séquence d'octets invalide pour l'encodage « UTF8 » : 0xe9 0x64 0x2e
0xe9 étant le code du E accent aigu en LATIN1, généralement ça indique que les contenus sont plutôt en LATIN1
et pas en UTF-8.
Si le cluster a été initialisé avec initdb --no-locale --encoding=SQL_ASCII comme précisé dans le 3eme message.
il ne devrait pas être possible d'avoir cette erreur, et d'ailleurs pas non plus cette autre erreur:
ERREUR: l'encodage « SQL_ASCII » ne correspond pas à la locale « fr_FR.UTF-8 »
Peut-être que vous mélangez les résultats et les commandes qui viennent de plusieurs tentatives différentes?
@DanielVerite
http://blog-postgresql.verite.pro/
Hors ligne
A propos de cette erreur
ERREUR: séquence d'octets invalide pour l'encodage « UTF8 » : 0xe9 0x64 0x2e
0xe9 étant le code du E accent aigu en LATIN1, généralement ça indique que les contenus sont plutôt en LATIN1
et pas en UTF-8.Si le cluster a été initialisé avec initdb --no-locale --encoding=SQL_ASCII comme précisé dans le 3eme message.
il ne devrait pas être possible d'avoir cette erreur, et d'ailleurs pas non plus cette autre erreur:ERREUR: l'encodage « SQL_ASCII » ne correspond pas à la locale « fr_FR.UTF-8 »
Peut-être que vous mélangez les résultats et les commandes qui viennent de plusieurs tentatives différentes?
En effet, c'est possible.
Afin d'etre sur des résultats, j'ai tout refait de A à Z moi même à partir de l'INITDB.
Je n'ai pas vu passer d'erreurs de transcodage, j'attend demain que mes applicatifs valident ou non le transfert de données...
je vous tiens au courant pour demain.
Encore merci
Hors ligne
Bonjour,
petit retour d'expérience et message de remerciement à votre égard.
J'ai donc réinitialisé ma base complètement avec un Initdb en SQL_ASCII.
Ensuite, j'ai exporté mes données en UTF-8, réencodé mon fichier d'export avec iconv.
J'ai pu recommencer un initdb en mode normal cette fois afin de ré-importer le dump converti.
Ceci m'a permis de passer ma base en UTF8.
Encore merci à vous pour l'aide apportée.
Hors ligne
