Discussion :

[MissTi]

Bonjour à tous,

Une base de données a été créée afin de partager des infos sur un serveur postgresql. Afin d'en simplifier l'exploitation (et de parer aux demandes en attendant d'avoir un interfaçage), nous avons installé des connecteurs ODBC sur les différents postes et un accès par Access. (là n'est pas le débat, svp...)
Nous rencontrons beaucoup d'erreurs du type "La connection ODBC a échoué" depuis Access sans plus d'information.
A force de chercher, j'ai fini par comprendre: il s’agirait d'encodage de caractères au niveau des tables faisant office de dictionnaires de données.

Les dictionnaires de données sont fournis et imposés au niveau national. Nous les récupérons au format csv/WIN1252, les convertissons et intégrons en dbf/UTF-8.

Sauf que lorsque je tente une extraction sur psql, j'ai le message suivant:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

\copy (select * from bd_eauxdouces.ds_parametre ) TO 'd:\parametres.csv' CSV

ERREUR: le caractère dont la séquence d'octets est 0xce 0xbb dans l'encodage "UTF-8" n'a pas d'équivalent dans l'encodage "WIN1252"

En fouillant encore un peu plus (par colonne et par lots d'identifiants... ouais, c'est un peu.... ) et en corrigeant à la main, j'arrive à faire sauter certaines erreurs... Et d'autres apparaissent quand je fais un export global d'une table.

Je suis prête à me fader un script de requêtes pour tester et corriger tous les champs de toutes les tables nécessaires.
Sauf que je ne sais pas comment lui dire de me remplacer le caractère 0xbb par " ? ou de me trouver tous les enregistrements avec ce de 0xce ?
Bref comment débusquer les caractères hexadécimaux ? Je cherche quelque chose du genre:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT * from bd_eauxdouces.ds_parametre where position(lblongparametre, '\xbb') <> 0 ;

Ai-je un moyen de me prévaloir de ces erreurs afin de ne plus avoir d'échec ODBC?

[alassanediakite]

Salut
Une piste avec utf8_to_windows_1252.
Vous avez aussi la possibilité de choisir un encodage de sortie avec l'option ENCODING de la commande COPY.
Pour ACCESS et la connexion ODBC, il faut préciser la version de ACCESS et le pilote ODBC. Pour avoir plus d'info sur les erreurs il faut voir le journal d'erreurs dans DOSSIER_DATA_DE_POSTGRES\pg_log
@+

[MissTi]

et le pilote ODBC

Ha haaaa! Ca m'a mis la puce à l'oreille.
J'avais appliqué un tutoriel disant qu'il fallait se connecter avec le pilote postgreSql "ANSI".
Hors, en fouinant, j'ai pu lire sur le web ceci

• PostgreSQL Unicode: use this if your database was set up with the UTF-8 character set.
• PostgreSQL ANSI: use this if your database was set up with a LATIN character set.

Comme je suis dns le cas d'une BD encodée en UTF-8, je suis dans le cas d'un driver en UNICODE.
Les 2-3 tests réalisés depuis ne posent plus de bugs.

Donc a priori, c'est résolu!
Merci alassanediakite !

[SQLpro]

Choisir un encodage UTF8 pour une base de données est la pire des imbécilités. En effet UTF8 est destiné à faire de la compression de données à la volée afin de réduire la volumétrie des flux HTPP des serveurs web !
Or les stratégies de stockage et d'indexation des bases de données s'opposent frontalement à l'utilisation de la compression UTF8 dans les recherches, les jointures, les opérations de tri et de groupage...
Certains SGBDR ont donné dans cette stupidité ce qui n'est pas sans conséquence.
Le meilleur conseil que je puisse vous donner et de reprendre votre base avec un encodage plus traditionnel et puis faire pisser à votre SGBDR en sortie (et uniquement en sortie- dans le DataSet) de l'UTF8 !
D'ailleurs le stockage de l'UTF 8 dans les SGBDR relèves quelques croustillante surprises !

A +

[MissTi]

La sentence est sans concession et je n'épiloguerai pas ici. Le serveur à pour vocation à avoir un interfaçage web.
J'en prend note et parlerai au prestataire d'infogérance de sa "pire des imbécilité".
Merci pour l'info et le conseil.