Vous n'êtes pas identifié(e).
Pages : 1
This is the end :-)
Problème identifié.
J'avais insérer le tuple suivant avant le dump:
113684 2 A\Saskatchewan\5351\2009-NML RV2412-WithSEG 664757qui lorsque je faisais une requête s'affichait comme:
select * from mytable where id=113684;
113684 | 2 | ASaskatchewan]19-NML RV2412-WithSEG | 664757Et en regardant mon fichier output.sql issue de mon dump il y avait bien un soucis de caractère UTF8 pour ce tuple m'empêchant une restauration complète de ma base de donnée....
Bonjour à tous,
n'ayant toujours pas trouvé la solution, j'essaie tout de même d'avancer....
J'ai effectué un dump de la table qui pose problème pour la restaurer dans une DB provisoire afin de trouver le problème et le résoudre.
pg_dump -O -o -n monschema -t monschema.matable -f output.sql madatabase
createdb test
psql test<output.sql
Et voici l'output:
SET
SET
SET
SET
SET
SET
SET
CREATE TABLE
COMMENT
COMMENT
COMMENT
COMMENT
ERROR: invalid byte sequence for encoding "UTF8": 0x80
HINT: This error can also happen if the byte sequence does not match the encoding expected by the server, which is controlled by "client_encoding".
CONTEXT: COPY genome, line 113917
ALTER TABLESi je regarde la ligne 113917 de mon fichier output.sql:
l.113917: 113610 1508 SPU10307KEN07-WithSEG 11588
Ma table a pour attribut: id(integer),num(integer),"comment"(text),tax(integer)
Je ne vois pas dans la ligne de problème de caractère.
Si je supprime la ligne 113917, et que je reinjecte output.sql:
ERROR: invalid byte sequence for encoding "UTF8": 0x80
HINT: This error can also happen if the byte sequence does not match the encoding expected by the server, which is controlled by "client_encoding".
CONTEXT: COPY genome, line 113916Une idée?
J'effectue mon dump via une connexion SSH sur Serveur Centos:
pg_dump -Fc -O -o -f dump.sql mydatabase
Ma base de données est encodée en UTF8.
show LC_CTYPE me donne :
lc_ctype
-------------
en_US.UTF-8Je récupère le dump pour une restauration sur un système MACOSX 10.6.3 (le fichier dump est un fichier binaire).
Cette database est encodée par défaut en UTF8 également.
Et c'est lors de la restauration que j'ai les erreurs.
J'ai testé la restauration de ce dump également sous Fedora, PSQL 8.4.4 avec les mêmes problèmes.
J'ai donc revérifié sur le même serveur d'origine si mon dump ne pose pas problème, et effectivement je n'arrive pas à le restaurer également sur le serveur Centos, alors que le base elle, est opérationnelle et fonctionne parfaitement.
Comment puis-je effectuer un dump fonctionnelle, ou identifier les tuples qui posent problèmes dans la BD pour le modifier ou les supprimer?
Merci pour vos conseils.
Bonjour à tous,
un petit message pour solliciter votre point de vue et votre aide. J'ai effectué un dump d'une BD sous PSQL 8.2.7 que je veux restaurer sur un autre serveur qui possède la version PSQL 8.2.5.
Cependant lors de la restauration , j'ai des erreurs qui apparaissent et qui m'empêchent de restaurer correctement la DB.
pg_restore dump.sql -O -d databaset -v
restauration des données de la table « toto »
pg_restore: [programme d'archivage (db)] Erreur pendant le traitement de la TOC (« PROCESSING TOC ») :
pg_restore: [programme d'archivage (db)] Erreur à partir de l'entrée TOC 2679; 0 913978 TABLE DATA toto user
pg_restore: [programme d'archivage (db)] COPY failed: ERREUR: S?quence d'octets invalide pour le codage ? UTF8 ? : 0x80
HINT: Cette erreur peut aussi survenir si la s?quence d'octets ne correspond pas au jeu de caract?res attendu par le serveur, le jeu ?tant contr?l? par ? client_encoding ?.
CONTEXT: COPY toto, ligne 113947Sur les deux serveurs l'encodage lors de la création de la DB est en UTF8. Seul la version de PSQL change.
Avez vous une solution me permettant de résoudre ce problème.
Merci d'avance.
Pages : 1