#1 Tue 28 April 2009 15:39
- Ouistiti
- Participant actif
- Date d'inscription: 4 Jun 2008
- Messages: 58
[PostgreSQL] Problème d'encodage
Bonjour,
je voudrai sauvegarder une de mes bases de données postgres (codée en UTF-8). Cependant, quand je lance la sauvegarde depuis PgAdmin j'ai le message d'erreur suivant :
pg_dump: la commande SQL a échoué
pg_dump: Message d'erreur du serveur : ERROR: invalid byte sequence for encoding "UTF8": 0xe97361
ASTUCE : This error can also happen if the byte sequence does not match the encoding expected by the server, which is controlled by "client_encoding".
pg_dump: La commande était : SELECT tableoid, oid, (SELECT rolname FROM pg_catalog.pg_roles WHERE oid = datdba) as dba, pg_encoding_to_char(encoding) as encoding, (SELECT spcname FROM pg_tablespace t WHERE t.oid = dattablespace) as tablespace, shobj_description(oid, 'pg_database') as description FROM pg_database WHERE datname = 'Thésaurii'
pg_dump: *** interrompu du fait d'erreurs
Le process a retourné le code de sortie 1.
Je me doute bien que cela est du au nom de ma table car le gros malin qui a créé cette table a osé mettre un accent dans son nom (malgré un codage UTF8 ). J'ai testé un "ALTER DATABASE" mais sans succès (ERROR: État SQL : 3D000)
Je voudrai donc savoir comment convertir l'encodage de ma table (si c'est possible mais je ne me fait pas d'illusion). J'ai bien trouvé quelques solutions mais je n'arrive pas à les mettre en oeuvre. Quelqu'un pourrait-il me décrire les étapes à suivre ? (Ou alors me dire comment changer le nom de ma table ?)
Cordialement.
Dernière modification par Ouistiti (Tue 28 April 2009 16:15)
Le Ouistiti
Hors ligne
#2 Tue 28 April 2009 16:30
- Nicolas Ribot
- Membre
- Lieu: Toulouse
- Date d'inscription: 9 Sep 2005
- Messages: 1544
Re: [PostgreSQL] Problème d'encodage
Bonjour,
je voudrai sauvegarder une de mes bases de données postgres (codée en UTF-8). Cependant, quand je lance la sauvegarde depuis PgAdmin j'ai le message d'erreur suivant :
pg_dump: la commande SQL a échoué
pg_dump: Message d'erreur du serveur : ERROR: invalid byte sequence for encoding "UTF8": 0xe97361
ASTUCE : This error can also happen if the byte sequence does not match the encoding expected by the server, which is controlled by "client_encoding".
pg_dump: La commande était : SELECT tableoid, oid, (SELECT rolname FROM pg_catalog.pg_roles WHERE oid = datdba) as dba, pg_encoding_to_char(encoding) as encoding, (SELECT spcname FROM pg_tablespace t WHERE t.oid = dattablespace) as tablespace, shobj_description(oid, 'pg_database') as description FROM pg_database WHERE datname = 'Thésaurii'
pg_dump: *** interrompu du fait d'erreurs
Le process a retourné le code de sortie 1.
Je me doute bien que cela est du au nom de ma table car le gros malin qui a créé cette table a osé mettre un accent dans son nom (malgré un codage UTF8 ). J'ai testé un "ALTER DATABASE" mais sans succès (ERROR: État SQL : 3D000)
Je voudrai donc savoir comment convertir l'encodage de ma table (si c'est possible mais je ne me fait pas d'illusion). J'ai bien trouvé quelques solutions mais je n'arrive pas à les mettre en oeuvre. Quelqu'un pourrait-il me décrire les étapes à suivre ? (Ou alors me dire comment changer le nom de ma table ?)
Cordialement.
Bonjour:
pour renomer une table:
ALTER TABLE name
RENAME TO new_name
mettre name entre guillements si le nom a ete crée entre guillements ("Thésauri" ici) ou s'il contient des caractères speciaux.
Sinon, il faut regler la valeur de la variable d'environnement CLIENT_ENCODING, si l'encodage par defaut de votre plateforme n'est pas le meme que celui de la base. Ca permettra au systeme de convertir correctement les lettres accentuées en fonction de l'encodage.
HTH
Nicolas
Hors ligne
#3 Tue 28 April 2009 16:39
- Ouistiti
- Participant actif
- Date d'inscription: 4 Jun 2008
- Messages: 58
Re: [PostgreSQL] Problème d'encodage
J'ai rajouter les guillemets dont j'avais oublié la nécessité mais il me dit maintenant que ma database n'existe pas.
Qu'elle pourrait en être la cause ?
Cordialement.
Le Ouistiti
Hors ligne
#4 Tue 28 April 2009 16:41
Re: [PostgreSQL] Problème d'encodage
Ouistiti,
J'ai rajouter les guillemets dont j'avais oublié la nécessité mais il me dit maintenant que ma database n'existe pas.
Qu'elle pourrait en être la cause ?
Cordialement.
Peux tu poster ta requête, le message d'erreur et le nom de ta base de données ? Merci.
Y.
Yves Jacolin, bénévole de l'association GeoRezo.net, agit au nom et pour le compte de l'association - Partageons ce qui nous départage !! - GeoRezo vous aide ? Aidez GeoRezo !
Hors ligne
#5 Tue 28 April 2009 16:51
- Nicolas Ribot
- Membre
- Lieu: Toulouse
- Date d'inscription: 9 Sep 2005
- Messages: 1544
Re: [PostgreSQL] Problème d'encodage
J'ai rajouter les guillemets dont j'avais oublié la nécessité mais il me dit maintenant que ma database n'existe pas.
Qu'elle pourrait en être la cause ?
Cordialement.
La casse est-elle respectée "Thésauri", apparemment, dans le message précédent.
Le schema est-il précisé ? la table est-elle dans le schema par defaut (public) ou dans un schema particulier dont il faudra preciser le nom (schema."table").
Nico
Hors ligne
#6 Tue 28 April 2009 17:00
- Ouistiti
- Participant actif
- Date d'inscription: 4 Jun 2008
- Messages: 58
Re: [PostgreSQL] Problème d'encodage
Le nom de ma base de données est : Thésaurii
La requête que j'ai testé est : ALTER DATABASE "Thésaurii" RENAME TO "Thesaurii"
Et le message d'erreur : ERROR: database "Thésaurii" does not exist État SQL :3D000
J'ai aussi essayé les requêtes suivantes pour la conversion d'encodage : ALTER DATABASE "Thésaurii" SET client_encoding TO 'iso-8859-1' et ALTER DATABASE "Thésaurii" SET NAMES 'iso-8859-1'
Et j'ai eu le même message d'erreur
PS: La casse est bien respectée; c'est bien Thésaurii mais ce n'est pas une table mais bel et bien une base de données
Dernière modification par Ouistiti (Tue 28 April 2009 17:04)
Le Ouistiti
Hors ligne
#7 Tue 28 April 2009 17:21
- Nicolas Ribot
- Membre
- Lieu: Toulouse
- Date d'inscription: 9 Sep 2005
- Messages: 1544
Re: [PostgreSQL] Problème d'encodage
Le nom de ma base de données est : Thésaurii
La requête que j'ai testé est : ALTER DATABASE "Thésaurii" RENAME TO "Thesaurii"
Et le message d'erreur : ERROR: database "Thésaurii" does not exist État SQL :3D000
J'ai aussi essayé les requêtes suivantes pour la conversion d'encodage : ALTER DATABASE "Thésaurii" SET client_encoding TO 'iso-8859-1' et ALTER DATABASE "Thésaurii" SET NAMES 'iso-8859-1'
Et j'ai eu le même message d'erreur
PS: La casse est bien respectée; c'est bien Thésaurii mais ce n'est pas une table mais bel et bien une base de données
Oups, pardon !
confusion de ma part entre table et base. j'ai lu un peu trop rapidement le premier message.
La base ne peut pas etre renommé.
Pouvez-vous essayer de creer une nouvelle base et de dumper le contenu de l'ancienne dans la nouvelle ? Ca peut se faire d'une seule commande avec pg_dump et psql, comme indiqué ici:
http://www.postgresql.org/docs/8.3/stat … gdump.html
Nico
Hors ligne
#8 Wed 29 April 2009 09:21
- Ouistiti
- Participant actif
- Date d'inscription: 4 Jun 2008
- Messages: 58
Re: [PostgreSQL] Problème d'encodage
Bonjour,
Au contraire, il est tout à fait possible de renommer une base. (cf http://docs.postgresqlfr.org/8.2/sql-alterdatabase.html) J'ai d'ailleurs tester cette requête sur d'autres base de mon serveur et cela fonctionne très bien pour elles.
J'ai aussi essayer de sauvegarder ma base Thésaurii via pgAdmin mais que ce soit en TAR, COMPRESS ou en PLAIN j'ai toujour le même message d'erreur (cf mon premier post).
Cordialement.
Le Ouistiti
Hors ligne
#9 Wed 29 April 2009 10:29
- Ouistiti
- Participant actif
- Date d'inscription: 4 Jun 2008
- Messages: 58
Re: [PostgreSQL] Problème d'encodage
Bon alors la j'en perd mon latin ... (et pas le iso-8859... )
Je vais finir par vous expliquer entièrement le contexte car il y aura peut être d'autres solutions.
Postgres est actuellement installé dans Program Files. Or, j'ai besoin qu'il soit dans un répertoire dont le chemin ne contient pas d'espace. Aussi, je voulais faire un backup de toute mes bases pour pouvoir refaire l'installation de Postgres et les restaurer ensuite. Donc, mis à part cette fameuse base "Thésaurii", les sauvegardes des bases ont fonctionné (format COMPRESS via pgAdmin). Cependant, quand je les restaure toujours via pgAdmin (histoire de voir si tout fonctionne) j'ai le message suivant : ATTENTION : erreurs ignorées lors de la restauration : 1
Le process a retourné le code de sortie 1.
Notez que le nombre d'erreurs ignorées varie selon les bases. Et je me rend compte alors qu'il me manquerait des enregistrements... (J'ai donc regardé dans la documentation de Postgres mais je dois vous dire que le code 1 ayant pour siginfication "WARNING" ne m'est pas d'une grande aide...)
Alors que se passe-t-il ? Est ce que mon PC s'acharne contre moi ou suis je juste en train de perdre la boule ? (NB: Toute autre proposition sera bienvenue... )
Cordialement.
Le Ouistiti
Hors ligne
#10 Wed 29 April 2009 10:29
- Nicolas Ribot
- Membre
- Lieu: Toulouse
- Date d'inscription: 9 Sep 2005
- Messages: 1544
Re: [PostgreSQL] Problème d'encodage
Bonjour,
Au contraire, il est tout à fait possible de renommer une base. (cf http://docs.postgresqlfr.org/8.2/sql-alterdatabase.html) J'ai d'ailleurs tester cette requête sur d'autres base de mon serveur et cela fonctionne très bien pour elles.
J'ai aussi essayer de sauvegarder ma base Thésaurii via pgAdmin mais que ce soit en TAR, COMPRESS ou en PLAIN j'ai toujour le même message d'erreur (cf mon premier post).
Cordialement.
Ah ok, merci pour l'info
Nico
Hors ligne
#11 Wed 29 April 2009 10:46
- Nicolas Ribot
- Membre
- Lieu: Toulouse
- Date d'inscription: 9 Sep 2005
- Messages: 1544
Re: [PostgreSQL] Problème d'encodage
Bon alors la j'en perd mon latin ... (et pas le iso-8859... )
Je vais finir par vous expliquer entièrement le contexte car il y aura peut être d'autres solutions.
Postgres est actuellement installé dans Program Files. Or, j'ai besoin qu'il soit dans un répertoire dont le chemin ne contient pas d'espace. Aussi, je voulais faire un backup de toute mes bases pour pouvoir refaire l'installation de Postgres et les restaurer ensuite. Donc, mis à part cette fameuse base "Thésaurii", les sauvegardes des bases ont fonctionné (format COMPRESS via pgAdmin). Cependant, quand je les restaure toujours via pgAdmin (histoire de voir si tout fonctionne) j'ai le message suivant : ATTENTION : erreurs ignorées lors de la restauration : 1
Le process a retourné le code de sortie 1.
Notez que le nombre d'erreurs ignorées varie selon les bases. Et je me rend compte alors qu'il me manquerait des enregistrements... (J'ai donc regardé dans la documentation de Postgres mais je dois vous dire que le code 1 ayant pour siginfication "WARNING" ne m'est pas d'une grande aide...)
Alors que se passe-t-il ? Est ce que mon PC s'acharne contre moi ou suis je juste en train de perdre la boule ? (NB: Toute autre proposition sera bienvenue... )
Cordialement.
Concernant la base avec accent, que donne la commande:
Code:
psql -U <user> -l
Elle doit lister toutes les bases, et peut etre faire apparaitre Thesauri sous un autre nom, peut etre avec des pb d'encoding pour le 'é' ?
Pouvez-vous egalement regarder le nom de la base tel qu'il apparait dans les tables systemes de PG:
Code:
select * from pg_database;
et nous dire le resultat ?
Autre piste, mais sous windows ca peut etre plus dur, car la console ne marche pas comme sous Linux/mac: se connecter a une autre base, puis tenter de se connecter a Thesauri en utilisant l'autocompletion de la console: juste taper la premiere lettre ('T' ici), puis taper la touche 'tab' pour voir les noms que propose PG.
Nico
Hors ligne
#12 Wed 29 April 2009 11:14
- Ouistiti
- Participant actif
- Date d'inscription: 4 Jun 2008
- Messages: 58
Re: [PostgreSQL] Problème d'encodage
Pour la commande : psql -U <user> -l -->
Code:
Liste des bases de donnÚes Nom | PropriÚtaire | Encodage ------------------+--------------+----------- BD_MÚtadonnÚes | postgres | LATIN1 CSNP_Geo | postgres | LATIN1 ThÚsaurii | postgres | UTF8 postgis | postgres | UTF8 postgres | postgres | SQL_ASCII template0 | postgres | SQL_ASCII template1 | postgres | SQL_ASCII template_postgis | postgres | UTF8 (8 lignes)
Pour la commande SQL --> le tableau de sortie me donne les noms de base suivantes: (notez que les deux base ayant des accents ont des noms vides (??))
Code:
"postgres" "template_postgis" "postgis" "template1" "template0" "" "CSNP_Geo" ""
Pour la commande de connexion à la base l'autocomplétion ne fonctionne pas (VIVA LINUX !). Cependant, il m'est possible de me connecter via la console en tapant "Thésaurii"
Cordialement.
Le Ouistiti
Hors ligne
#13 Wed 29 April 2009 11:29
- Nicolas Ribot
- Membre
- Lieu: Toulouse
- Date d'inscription: 9 Sep 2005
- Messages: 1544
Re: [PostgreSQL] Problème d'encodage
Pour la commande : psql -U <user> -l -->
Code:
Liste des bases de donnÚes Nom | PropriÚtaire | Encodage ------------------+--------------+----------- BD_MÚtadonnÚes | postgres | LATIN1 CSNP_Geo | postgres | LATIN1 ThÚsaurii | postgres | UTF8 postgis | postgres | UTF8 postgres | postgres | SQL_ASCII template0 | postgres | SQL_ASCII template1 | postgres | SQL_ASCII template_postgis | postgres | UTF8 (8 lignes)Pour la commande SQL --> le tableau de sortie me donne les noms de base suivantes: (notez que les deux base ayant des accents ont des noms vides (??))
Code:
"postgres" "template_postgis" "postgis" "template1" "template0" "" "CSNP_Geo" ""Pour la commande de connexion à la base l'autocomplétion ne fonctionne pas (VIVA LINUX !). Cependant, il m'est possible de me connecter via la console en tapant "Thésaurii"
Cordialement.
Serait-il possible de regler le probleme d'encodage entre le client et PG ? Ca peut se faire globalement au niveau de l'instance PG dans le fichier postgresql.conf ou par variable d'environnement.
Deja, si l'affichage des messages PG etaient corrects (avec les accents) peut etre l'acces aux bases accentuées se ferait mieux ?
l'encodage du client doit etre LATIN1 ou CP1252, ou un truc comme ca sous windows.
Nico
Hors ligne
#14 Wed 29 April 2009 12:21
- Ouistiti
- Participant actif
- Date d'inscription: 4 Jun 2008
- Messages: 58
Re: [PostgreSQL] Problème d'encodage
Bon je n'ai pas réussi a changer l'encodage que se soit dans postgresql.conf ou par la variable d'environnement... rien y fait j'ai toujours le même affichage.
Par contre, j'ai relancé ma requête SQL (select * from pg_database;) dans la console (car avant c'était via pgAdmin) et la j'ai cette erreur :
ThÚsaurii=# select * from pg_database;
ERROR: invalid byte sequence for encoding "UTF8": 0xe97361
ASTUCE : This error can also happen if the byte sequence does not match the enco
ding expected by the server, which is controlled by "client_encoding".
D'ailleurs j'ai toujour le meme message d'erreur de la console a chaque fois que je me connecte a une base :
Attention : l'encodage console (850) diffÞre de l'encodage Windows (1252).
Les caractÞres 8 bits peuvent ne pas fonctionner correctement. Voir
la page
rÚfÚrence de psql ½ Notes aux utilisateurs de Windows ╗ pour les dÚt
ails.
Dernière modification par Ouistiti (Wed 29 April 2009 12:22)
Le Ouistiti
Hors ligne
#15 Wed 29 April 2009 14:23
- Nicolas Ribot
- Membre
- Lieu: Toulouse
- Date d'inscription: 9 Sep 2005
- Messages: 1544
Re: [PostgreSQL] Problème d'encodage
Bon je n'ai pas réussi a changer l'encodage que se soit dans postgresql.conf ou par la variable d'environnement... rien y fait j'ai toujours le même affichage.
Par contre, j'ai relancé ma requête SQL (select * from pg_database;) dans la console (car avant c'était via pgAdmin) et la j'ai cette erreur :
ThÚsaurii=# select * from pg_database;
ERROR: invalid byte sequence for encoding "UTF8": 0xe97361
ASTUCE : This error can also happen if the byte sequence does not match the enco
ding expected by the server, which is controlled by "client_encoding".
D'ailleurs j'ai toujour le meme message d'erreur de la console a chaque fois que je me connecte a une base :
Attention : l'encodage console (850) diffÞre de l'encodage Windows (1252).
Les caractÞres 8 bits peuvent ne pas fonctionner correctement. Voir
la page
rÚfÚrence de psql ½ Notes aux utilisateurs de Windows ╗ pour les dÚt
ails.
Oui, pour ces pb, mieux vaut passer par la console plutot que par pgAdmin.
Concernant le codepage windows, il est possible de faire un chcp <nouveau code> pour changer le codepage de la console.
(et en copiant/collant le nom de la base avec le caractere bizarre, ca ne marche pas non plus ?)
Hors ligne
#16 Wed 29 April 2009 14:56
- Ouistiti
- Participant actif
- Date d'inscription: 4 Jun 2008
- Messages: 58
Re: [PostgreSQL] Problème d'encodage
Comment se fait-il que la console windows soit en codepage 850 (LatinI) ne gère pas le codage Windows (WinLatinI) c'est quand même hallucinant non ? Un pote me disais que des fois les mec qui conçoivent windows doivent fumer ou boire entre 2 programmations... Moi je dirai carément qu'ils se piquent !!
Je profite donc de ce message pour pousser un coup de geule : Windows c'est de la m***** ! Voila ça me soulage même pas mais on n'y peut rien...
Donc Nicolas tu l'auras compris j'ai tenté de changer le codepage mais ça n'a rien changé.
(et en copiant/collant le nom de la base avec le caractere bizarre, ca ne marche pas non plus ?)
Je ne comprends pas ce que tu veux dire. Tu veux que je copie/colle ça où ? J'arrive très bien à me connecter à ma base Thésaurii et même a sélectionner des enregistrements dans mes tables via la console
Le Ouistiti
Hors ligne
#17 Wed 29 April 2009 15:30
- Nicolas Ribot
- Membre
- Lieu: Toulouse
- Date d'inscription: 9 Sep 2005
- Messages: 1544
Re: [PostgreSQL] Problème d'encodage
Comment se fait-il que la console windows soit en codepage 850 (LatinI) ne gère pas le codage Windows (WinLatinI) c'est quand même hallucinant non ? Un pote me disais que des fois les mec qui conçoivent windows doivent fumer ou boire entre 2 programmations... Moi je dirai carément qu'ils se piquent !!
Je profite donc de ce message pour pousser un coup de geule : Windows c'est de la m***** ! Voila ça me soulage même pas mais on n'y peut rien...
Donc Nicolas tu l'auras compris j'ai tenté de changer le codepage mais ça n'a rien changé.
Oui, je me rappelle m'etre arraché les cheveux aussi avec ces pb d'encodage sous windows. Affreux.
Aurais-tu la possibilité de te connecter a ta base depuis une autre machine (linux, vmware par exemple) et se servir de cette machine comme client. ca peut peut-etre aider.
(et en copiant/collant le nom de la base avec le caractere bizarre, ca ne marche pas non plus ?)
Je ne comprends pas ce que tu veux dire. Tu veux que je copie/colle ça où ? J'arrive très bien à me connecter à ma base Thésaurii et même a sélectionner des enregistrements dans mes tables via la console
Par exemple dans la commande alter database set name = ...
utiliser le nom tel qu'il est affiché.
Hors ligne
#18 Wed 29 April 2009 17:16
- Ouistiti
- Participant actif
- Date d'inscription: 4 Jun 2008
- Messages: 58
Re: [PostgreSQL] Problème d'encodage
Bon j'ai réussi à faire en sorte que ma console gère mon encodage (chcp 1252--> je n'avais pas vu que ce code existait dans la documentation)
Maintenant, quand je lance ma requête SQL (select * from pg_database;) j'obtiens le résultat suivant :
Code:
postgres=# select * from pg_database ; datname | datdba | encoding | datistemplate | datallowconn | datconnli mit | datlastsysoid | datfrozenxid | dattablespace | datconfig | d atacl ------------------+--------+----------+---------------+--------------+---------- ----+---------------+--------------+---------------+-----------+---------------- --------------------- postgres | 10 | 0 | f | t | -1 | 10818 | 526 | 1663 | | template_postgis | 10 | 6 | f | t | -1 | 10818 | 526 | 1663 | | postgis | 10 | 6 | f | t | -1 | 10818 | 526 | 1663 | | template1 | 10 | 0 | t | t | -1 | 10818 | 526 | 1663 | | {=c/postgres,po stgres=CTc/postgres} template0 | 10 | 0 | t | f | -1 | 10818 | 526 | 1663 | | {=c/postgres,po stgres=CTc/postgres} ThÚsaurii | 10 | 6 | f | t | -1 | 10818 | 526 | 1663 | | CSNP_Geo | 10 | 8 | f | t | -1 | 10818 | 526 | 1663 | | BD_MÚtadonnÚes | 10 | 8 | f | t | -1 | 10818 | 526 | 1663 | | (8 lignes)
Pour ce qui est de la connexion via une autre machine, ca ne fonctionne malheureusement pas malgré mes modification dans postgresql.conf (listen_adresses : '*')
Par contre, j'ai réussi aussi a faire mon alter database Thésaurii et j'ai pu la sauvegarder donc ce pb est règlé. Cependant, un problème en appelant un autre, j'ai toujours des souci pour les restaurer... j'ai des erreurs lors de leurs restauration dans une base que j'ai nommée "test". D'où pourrait venir le hic ? du nouveau nom de la base ?
Dernière modification par Ouistiti (Wed 29 April 2009 17:18)
Le Ouistiti
Hors ligne
#19 Thu 30 April 2009 11:08
- Nicolas Ribot
- Membre
- Lieu: Toulouse
- Date d'inscription: 9 Sep 2005
- Messages: 1544
Re: [PostgreSQL] Problème d'encodage
Bon j'ai réussi à faire en sorte que ma console gère mon encodage (chcp 1252--> je n'avais pas vu que ce code existait dans la documentation)
Maintenant, quand je lance ma requête SQL (select * from pg_database;) j'obtiens le résultat suivant :Code:
postgres=# select * from pg_database ; datname | datdba | encoding | datistemplate | datallowconn | datconnli mit | datlastsysoid | datfrozenxid | dattablespace | datconfig | d atacl ------------------+--------+----------+---------------+--------------+---------- ----+---------------+--------------+---------------+-----------+---------------- --------------------- postgres | 10 | 0 | f | t | -1 | 10818 | 526 | 1663 | | template_postgis | 10 | 6 | f | t | -1 | 10818 | 526 | 1663 | | postgis | 10 | 6 | f | t | -1 | 10818 | 526 | 1663 | | template1 | 10 | 0 | t | t | -1 | 10818 | 526 | 1663 | | {=c/postgres,po stgres=CTc/postgres} template0 | 10 | 0 | t | f | -1 | 10818 | 526 | 1663 | | {=c/postgres,po stgres=CTc/postgres} ThÚsaurii | 10 | 6 | f | t | -1 | 10818 | 526 | 1663 | | CSNP_Geo | 10 | 8 | f | t | -1 | 10818 | 526 | 1663 | | BD_MÚtadonnÚes | 10 | 8 | f | t | -1 | 10818 | 526 | 1663 | | (8 lignes)Pour ce qui est de la connexion via une autre machine, ca ne fonctionne malheureusement pas malgré mes modification dans postgresql.conf (listen_adresses : '*')
Par contre, j'ai réussi aussi a faire mon alter database Thésaurii et j'ai pu la sauvegarder donc ce pb est règlé. Cependant, un problème en appelant un autre, j'ai toujours des souci pour les restaurer... j'ai des erreurs lors de leurs restauration dans une base que j'ai nommée "test". D'où pourrait venir le hic ? du nouveau nom de la base ?
salut, mieux effectivement, mais le nom de la base sort tjs pourri. enfin, si vous avez reussi a la renommer, tout va bien
Concernant l'acces distant, il faut aussi et surtout editer le fichier pg_hba.conf, qui controle comment les hotes accedent a PG:
il va definir les adresses permises pour se connecter, les utilisateurs, les bases sur lesquelles on se connecte, le mode d'authentification, etc.
Concernant les erreurs de restauration, quelles sont-elles ? pourriez-vous envoyer le log de ces erreurs (seule la premiere erreur de la liste est significative)
Nico
Hors ligne
#20 Thu 30 April 2009 12:28
- Ouistiti
- Participant actif
- Date d'inscription: 4 Jun 2008
- Messages: 58
Re: [PostgreSQL] Problème d'encodage
Bonjour,
J'ai donc sauvegardé ma base "BD_Métadonnées" et l'ai restaurer dans une base "test". à la fin de la restauration j'ai une erreur dont voici le log :
Code:
pg_restore: création de PROCEDURAL LANGUAGE plpgsql 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 986; 2612 16386 PROCEDURAL LANGUAGE plpgsql postgres pg_restore: [programme d'archivage (db)] could not execute query: ERROR: language "plpgsql" already exists Command was: CREATE PROCEDURAL LANGUAGE plpgsql;
Je comprends maintenant d'où vient l'erreur, il ne peut recréer un langage qui existe déjà... OK. Cependant quand je compare mes bases, je vois que j'ai 13 transtypages pour "BD_Métadonnées" et aucun pour "test". Je ne sais pas à quoi correspondent mes transtypages mais est-ce que cela est dangeureux pour l'intégrité de ma base ? Est ce que si ces transtypages sont présent dans une des bases du serveur elles n'ont pas besoins d'en disposer chacune pour pouvoir les utiliser ?
Je suis désolé si mes questions semblent trop prises de tête, mais il y a une application (MD Web) qui tourne avec ces bases et je ne voudrai pas qu'il y ai le moindre problème lors de la restauration une fois que j'aurais réinstaller postgres... Vous me comprendrez je pense !
Cordialement.
PS : Deuxième essai avec une deuxième base, cette fois ci j'ai 23 erreurs dont la premières est la même que précedemment et les suivantes concernent la création de fonctions et sont de ce type :
Code:
pg_restore: création de FUNCTION _st_coveredby(geometry, geometry) pg_restore: [programme d'archivage (db)] Erreur à partir de l'entrée TOC 36; 1255 18539 FUNCTION _st_coveredby(geometry, geometry) postgres pg_restore: [programme d'archivage (db)] could not execute query: ERROR: could not find function "coveredby" in file "C:/Program Files/PostgreSQL/8.2/lib/liblwgeom.dll" Command was: CREATE FUNCTION _st_coveredby(geometry, geometry) RETURNS boolean AS '$libdir/liblwgeom', 'coveredby' LANGUAGE c IMM... pg_restore: [programme d'archivage (db)] could not execute query: ERROR: function public._st_coveredby(geometry, geometry) does not exist Command was: ALTER FUNCTION public._st_coveredby(geometry, geometry) OWNER TO postgres;
Et là, j'ai tout mes transtypages... Mais par contre il me manque 11 fonctions !
Dernière modification par Ouistiti (Thu 30 April 2009 12:39)
Le Ouistiti
Hors ligne
#21 Thu 30 April 2009 14:45
- Nicolas Ribot
- Membre
- Lieu: Toulouse
- Date d'inscription: 9 Sep 2005
- Messages: 1544
Re: [PostgreSQL] Problème d'encodage
Bonjour,
J'ai donc sauvegardé ma base "BD_Métadonnées" et l'ai restaurer dans une base "test". à la fin de la restauration j'ai une erreur dont voici le log :Code:
pg_restore: création de PROCEDURAL LANGUAGE plpgsql 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 986; 2612 16386 PROCEDURAL LANGUAGE plpgsql postgres pg_restore: [programme d'archivage (db)] could not execute query: ERROR: language "plpgsql" already exists Command was: CREATE PROCEDURAL LANGUAGE plpgsql;Je comprends maintenant d'où vient l'erreur, il ne peut recréer un langage qui existe déjà... OK. Cependant quand je compare mes bases, je vois que j'ai 13 transtypages pour "BD_Métadonnées" et aucun pour "test". Je ne sais pas à quoi correspondent mes transtypages mais est-ce que cela est dangeureux pour l'intégrité de ma base ? Est ce que si ces transtypages sont présent dans une des bases du serveur elles n'ont pas besoins d'en disposer chacune pour pouvoir les utiliser ?
Je suis désolé si mes questions semblent trop prises de tête, mais il y a une application (MD Web) qui tourne avec ces bases et je ne voudrai pas qu'il y ai le moindre problème lors de la restauration une fois que j'aurais réinstaller postgres... Vous me comprendrez je pense !
Cordialement.
PS : Deuxième essai avec une deuxième base, cette fois ci j'ai 23 erreurs dont la premières est la même que précedemment et les suivantes concernent la création de fonctions et sont de ce type :Code:
pg_restore: création de FUNCTION _st_coveredby(geometry, geometry) pg_restore: [programme d'archivage (db)] Erreur à partir de l'entrée TOC 36; 1255 18539 FUNCTION _st_coveredby(geometry, geometry) postgres pg_restore: [programme d'archivage (db)] could not execute query: ERROR: could not find function "coveredby" in file "C:/Program Files/PostgreSQL/8.2/lib/liblwgeom.dll" Command was: CREATE FUNCTION _st_coveredby(geometry, geometry) RETURNS boolean AS '$libdir/liblwgeom', 'coveredby' LANGUAGE c IMM... pg_restore: [programme d'archivage (db)] could not execute query: ERROR: function public._st_coveredby(geometry, geometry) does not exist Command was: ALTER FUNCTION public._st_coveredby(geometry, geometry) OWNER TO postgres;Et là, j'ai tout mes transtypages... Mais par contre il me manque 11 fonctions !
Concernant les transtypages, ca peut etre embetant s'ils manquent, effectivement.
Ce sont des transtypages Postgres ou bien crées par MDWeb ? bizarre qu'ils aient sautés lors du restore.
Concernat les autres erreurs, pb classique lorsqu'on a postgis installée: Si les versions de la dll liblwgeom ne correspondent pas, ou si le chemin n'est plus le bon, ce genre de pb arrive.
Vous avez bougé PG n'est-ce pas ? si c'est le cas, liblwgeom.dll a aussi bougé. Plusieurs options:
- soit editer le fichier du dump et modifier le chemin C:/Program Files/PostgreSQL/8.2/lib/liblwgeom.dll a la main pour faire pointer sur le bon endroit
- soit virer toutes les lignes (plusieurs centaines ou milliers) correspondant a la recreation de postgis. Il faudra alors reinstaller postgis sur la base cible apres avoir fait le restore,
- soit utiliser les scripts SQL lwpostgis_upgrade.sql.
Pour eviter ces soucis, le plus simple est de tjs créer ses données dans des schemas differents de "public", puis de ne dumper que ses propres schemas lors d'une sauvegarde.
On recrée alors une base, on installe postgis, et on restaure ses schémas.
Nico
Hors ligne
#22 Mon 11 May 2009 14:55
- Ouistiti
- Participant actif
- Date d'inscription: 4 Jun 2008
- Messages: 58
Re: [PostgreSQL] Problème d'encodage
Bonjour Nicolas,
après un peu de repos je pense que ca devrait aller mieux.... d'ailleurs, je ne sais pas comment mais mes problèmes de transtypages se sont envolés : ça y est ils sont créés dans la restauration (pi tèt que c'est le PC qui avait besoin de repos :p)
Pour ce qui est des fonctions, et bien rien a changé. J'ai vérifié le chemin de liblwgeom.dll et mon dump pointe vers le bon chemin. Du coup j'ai testé la mise a jour lwpostgis mais rien a changé. Je met ma requête de mise a jour au cas ou je me serai trompé quelque part :
$ psql -d ma_db -U superuser -f c:\...\lwpostgis_upgrade.sql
J'aurai bien essayé la dernière solution que tu avais proposée mais à vrai dire j'ai pas tout bien compris ce qu'il fallait faire ! Mais c'est quand même bizarre que cette fonction ne soit pas dans la dll telle qu'elle existe dans postgres alors qu'elle est bel et bien présente dans ma base de données, non ?
Cordialement.
Le Ouistiti
Hors ligne
#23 Mon 11 May 2009 15:33
- Nicolas Ribot
- Membre
- Lieu: Toulouse
- Date d'inscription: 9 Sep 2005
- Messages: 1544
Re: [PostgreSQL] Problème d'encodage
Bonjour Nicolas,
après un peu de repos je pense que ca devrait aller mieux.... d'ailleurs, je ne sais pas comment mais mes problèmes de transtypages se sont envolés : ça y est ils sont créés dans la restauration (pi tèt que c'est le PC qui avait besoin de repos :p)
Pour ce qui est des fonctions, et bien rien a changé. J'ai vérifié le chemin de liblwgeom.dll et mon dump pointe vers le bon chemin. Du coup j'ai testé la mise a jour lwpostgis mais rien a changé. Je met ma requête de mise a jour au cas ou je me serai trompé quelque part :
$ psql -d ma_db -U superuser -f c:\...\lwpostgis_upgrade.sql
J'aurai bien essayé la dernière solution que tu avais proposée mais à vrai dire j'ai pas tout bien compris ce qu'il fallait faire ! Mais c'est quand même bizarre que cette fonction ne soit pas dans la dll telle qu'elle existe dans postgres alors qu'elle est bel et bien présente dans ma base de données, non ?
Cordialement.
Bonjour,
hmm, oui bizarre pour ces fonctions manquantes.
ca fait penser a un pb de version de postgis: une vieille DLL qui traine => pas les fonctions dedans. Un script a jour au niveau SQL (lwpostgis.sql) => une definition de fonction correcte, mais pas utilisable car pointant sur une mauvaise DLL.
Peux-tu verifier la version de la dll postgis (il y a un moyen de verifier sous windows, mais je ne m'en souviens plus)
Autre solution: reinstaller postgis en verifiant bien si la nouvelle dll remplace l'ancienne (pb de lock ou d'acces au fichiers ?)
Nicolas
Hors ligne
#24 Mon 11 May 2009 17:23
- Ouistiti
- Participant actif
- Date d'inscription: 4 Jun 2008
- Messages: 58
Re: [PostgreSQL] Problème d'encodage
J'ai donc pu vérifier ma version de postgis et voici ce que j'obtiens : "POSTGIS="1.1.6" GEOS="2.2.3-CAPI-1.1.1" PROJ="Rel. 4.5.0, 22 Oct 2006" USE_STATS"
Mais à quoi puis je la comparer ? Et est-ce sur que je retrouverai toutes mes fonctions dans les nouvelles versions de postgis ou comment pourrais-je le vérifier ? Car à la limite si je suis sur de pouvoir retrouver les fonctions qui me manquent dans les nouvelles versions de postgis, puisque je dois tout réinstaller de toute façon, autant arrêter de me (et aussi de te) prendre la tête puisqu'il n'y a plus que les fonctions qui posent problème.
Le Ouistiti
Hors ligne
#25 Mon 11 May 2009 17:40
- Nicolas Ribot
- Membre
- Lieu: Toulouse
- Date d'inscription: 9 Sep 2005
- Messages: 1544
Re: [PostgreSQL] Problème d'encodage
J'ai donc pu vérifier ma version de postgis et voici ce que j'obtiens : "POSTGIS="1.1.6" GEOS="2.2.3-CAPI-1.1.1" PROJ="Rel. 4.5.0, 22 Oct 2006" USE_STATS"
Mais à quoi puis je la comparer ? Et est-ce sur que je retrouverai toutes mes fonctions dans les nouvelles versions de postgis ou comment pourrais-je le vérifier ? Car à la limite si je suis sur de pouvoir retrouver les fonctions qui me manquent dans les nouvelles versions de postgis, puisque je dois tout réinstaller de toute façon, autant arrêter de me (et aussi de te) prendre la tête puisqu'il n'y a plus que les fonctions qui posent problème.
Tu peux comparer cela avec le contenu de lwpostgis.sql.
Voila donc la version de postgis dll (ces fonctions de version proviennent de la dll)
Une version 1.1.6 est ancienne et ne contient pas de st_*.
Le mix entre version dll et version sql semble s'etre produit.
Effectivement, si tu dois repartir sur une nouvelle base (ahah, humour), autant prendre une version recente de postgis: 1.3.5 ou 1.3.6.
Elle apportera de nombreuses ameliorations et toutes les fonctions st_* (nouveau nom des fonctions spatiales) seront presentes.
Nico
Hors ligne
#26 Mon 11 May 2009 18:14
- Nicolas Ribot
- Membre
- Lieu: Toulouse
- Date d'inscription: 9 Sep 2005
- Messages: 1544
Re: [PostgreSQL] Problème d'encodage
Ouistiti a écrit:J'ai donc pu vérifier ma version de postgis et voici ce que j'obtiens : "POSTGIS="1.1.6" GEOS="2.2.3-CAPI-1.1.1" PROJ="Rel. 4.5.0, 22 Oct 2006" USE_STATS"
Mais à quoi puis je la comparer ? Et est-ce sur que je retrouverai toutes mes fonctions dans les nouvelles versions de postgis ou comment pourrais-je le vérifier ? Car à la limite si je suis sur de pouvoir retrouver les fonctions qui me manquent dans les nouvelles versions de postgis, puisque je dois tout réinstaller de toute façon, autant arrêter de me (et aussi de te) prendre la tête puisqu'il n'y a plus que les fonctions qui posent problème.
Tu peux comparer cela avec le contenu de lwpostgis.sql.
Voila donc la version de postgis dll (ces fonctions de version proviennent de la dll)
Une version 1.1.6 est ancienne et ne contient pas de st_*.
Le mix entre version dll et version sql semble s'etre produit.
Effectivement, si tu dois repartir sur une nouvelle base (ahah, humour), autant prendre une version recente de postgis: 1.3.5 ou 1.3.6.
Elle apportera de nombreuses ameliorations et toutes les fonctions st_* (nouveau nom des fonctions spatiales) seront presentes.
Nico
Concernant ces problemes de version, de fonctions differentes et de restauration, voila ce que je peux te dire:
Ce qui est important lors de la restauration d'une base postgis A vers une base B, c'est la correspondance entre la version de postgis dans la base originale (A) et la version de la base qui va etre restaurée B:
Si la version A est plus recente que la version B, alors certaines fonctions presentes dans la A vont etre absentes de la B, car non définies par le script SQL Postgis.
Si la version B est plus recente, il doit y avoir moins de problemes, car en general, une certains retrocompatibilité est maintenue dans postgis (conservation d'anciennes fonctions, ou d'anciennes signatures de fonctions).
Ce n'est pas toujours vrai, d'ou les procedures de restauration avec upgrade decrites sur la page de doc de postgis.
Ce que j'ai aussi vu sur les forums, ce sont des problemes de version postgis au sein d'une seule base, problemes qui arrivent lorsqu'un script lwpostgis.sql est chargé dans une base, et que la dll postgis attachée a cette base n'est pas de la meme version:
On peut alors definir au niveau SQL des fonctions qui font appel a la DLL postgis, DLL ne contenant justement pas ces fonctions.
C'est alors en comparant la version de postgis (fonction provenant de la dll) avec le contenu du script SQL lwpostgis.sql que l'on peut voir si les versions correspondent.
Pour eviter cela, une methode consiste a utiliser des schemas pour stocker les tables de son application:
Lors d'une sauvegarde complete d'une base postgis avec pg_dump, les types, fonctions et operateurs sont egalement sauvegardés, ou du moins leurs definitions en SQL.
Lors de la restauration complete d'une base postgis, le lien entre les fonctions SQL et leur appel dans la DLL depend de la version de la DLL. si celle-ci n'est pas la meme que celle de la base originale, des pb arrivent.
En definissant les tables de son application dans un schema propre, app par exemple, distinct du schma 'public' par defaut, on peut alors ne dumper que le schema app, en laissant de cote la partie postgis (définie par défaut dans le schema 'public').
Lors de la restauration, on crée sa base, on crée le schema cible, et on restaure son dump dans ce schema.
Ainsi, la version de postgis sur la base restaurée ne peut pas etre 'cassée'.
Pour travailler plus facilement et acceder aux tables de son application sans preciser tout le temps app.table, on peut mettre a jour la variable search_path, dans postgresql.
Cette variable définie la liste des schemas par défaut. Le schema 'public' est dans cette liste:
Code:
set search_path to 'public', 'app', '$user';
J'espere ne pas avoir ete trop confus.
Nicolas
Dernière modification par Nicolas Ribot (Mon 11 May 2009 18:18)
Hors ligne