Vous n'êtes pas identifié(e).
- Contributions : Récentes | Sans réponse
Pages : 1
#1 Re : PgAdmin3 » Problème d'import/export avec des accents » 19/01/2012 10:05:24
bonjour,
c'est peut être un peu tard, mais le fichier dans lequel est faite la sauvegarde peut lui aussi être interprété suivant un encodage par défaut du logiciel d'édition.
J'utilise PSPad, et dans certain cas il m'a fallut forcer l'encodage de fichiers pour qu'il soit le même que celui de la base, en tout cas pour l'affichage.
Ensuite, il faut bien vérifier que la sauvegarde soit configurée pour être au bon format, puis de même pour l'importation des données.
Dans pgAdmin en français, dernière ligne "codage" dans la fenêtre de sauvegarde de la base.
(j'utilise pgAdmin 1.12.3, Postgre 8.4, sous ubuntu, je viens de tester la sauvegarde, je n'ai pas de problème)
#2 ODBC » PGSQL ODBC et windows 7 (?) » 16/01/2012 11:48:42
- cébé
- Réponses : 0
Bonjour ,
(et bonne année 
)
je viens de migrer vers un nouveau PC, avec Windows 7, & Office 2010
J'ai un fichier excel qui a un lien avec la base de données PG SQL.
pgAdmin s'est installé sans souci.
Les drivers ODBC pour 64 bits également.
Par contre, lorsque je veux mettre à jour les données avec Excel, j'ai un medsage d'erreur indiquant :
"[Microsoft][Gestionnaire de pilotes ODBC] Source de données introuvable et nom de pilote non spécifié"
Normal puisque c'est un nouveau PC, le la source de données n'existe plus (et je n'ai pas pris soin de la copier de mon ancien PC...)
J'ai alors la possibilité de créer une nouvelle source de données.
Mais en sélectionnant
"[Microsoft][Gestionnaire de pilotes ODBC] La source de données (DSN) spécifiée présente une incompatibilité d'architecture entre le pilote et l'application".
Une rapide demande à google m'a permis de trouver une discussion (sur un autre forum, datant de 2008) indiquant d'utiliser d'autres drivers, mais le résultat est le meme.
Qui peux m'aider sur ce cas tordu ... ?
merci d'avance
cébé
#3 Re : ODBC » Requete -> ODBC -> Excel » 21/04/2011 15:51:48
Les représentations sont de toute façon un sacré dossier !
Déjà lors de la mise en place de l'intranet, nous avons eut du fil à retordre entre les codages du serveur, de la BD, du client, etc etc 
C'est difficile de comprendre qui fait quoi dans tout ca.
Poussé par la curiosité, je suis allé jusqu'au bout, et j'ai recherché les champs qui posaient problème :
SELECT replace(commentaire, E'\xc2\x80', '--------------------------------------------------------------------*******************************************') AS commentaire
FROM facture_fournisseur
C'est une vieille information, qui est passée par diverses conversions et importations à partir de fichiers Excel. A priori, un caractère € qui posait problème. Il n'y avait donc qu'une ligne en défaut, et le caractère était bien sur invisible.
#4 Re : ODBC » Requete -> ODBC -> Excel » 21/04/2011 15:21:32
Youhou !!
Ca fonctionne avec le E'\xc2\x80'
Je n'ai pas bien saisie l'histoire de code point,mais l'essentiel est que ca fonctionne.
C'est pour un outil interne, donc tout va bien.
Merci beaucoup à vous en tout cas !
Tant sur la réponse que la disponibilité et la réactivité !
#5 Re : ODBC » Requete -> ODBC -> Excel » 21/04/2011 15:05:59
Est-ce qu'il n'y 'a pas une fonction, sur le meme principe que replace, qui convertisse directement les résultats d'un codage à l'autre ? C'est ce que j'ai cherché au début mais que je n'ai pas trouvé.
#6 Re : ODBC » Requete -> ODBC -> Excel » 21/04/2011 14:56:50
Le caractère en erreur est le 0xC280 que j'utilise dans le replace.
Je suis passé à l'éditeur de requetes de excel pour sélectionner les données, et c'est une saleté de champs commentaire qui est en cause, bourré d'accents, de caractères € n° et tout ça....
Plus trace du 0xC28C.... y'a un truc que je ne sais pas. C'est peut etre parceque je ramène moins de données, juste ce dont j'ai besoin dans excel.
Pour information, j'ai utilisé une autre base avec le même schéma, et cela fonctionne très bien, mais c'est une base beaucoup plus légère (moins de données), et probablement pas d'accents ( et autres) car je n'en met souvent pas...
#7 Re : ODBC » Requete -> ODBC -> Excel » 21/04/2011 14:24:41
Pas la peine d'utiliser regexp_replace. La fonction replace simple suffit:
SELECT replace(colonne,'\u008C',' ') from tableE;
Le plus simple, c'est d'utiliser la notation \u, qui permet d'entrer le caractère dans sa représentation "code point".
Arf, j'ai buté ce matin sur un problème tout bête :
SELECT replace(colonne,'\u0x8C',' ') from tableE;
J'avais pas fait attention que le 00 était une faute de frappe, mais qu'il fallait comprendre 0x
J'ai donc créé une vue
CREATE VIEW tableE_v AS
SELECT replace(colonne,'\u0xC28C',' ') from tableE;
et je viens chercher les données sur cette vue.
Et bien :
1/ j'ai toujours le problème
2/ PgAdmin me dit que :
ATTENTION: utilisation non standard d'un échappement dans une chaîne littérale
LINE 6: ... replace(facture_fournisseur.commentaire,'\u0xC280'...
^
HINT: Utilisez la syntaxe de la chaîne d'échappement pour les échappements,
c'est-à-dire E'\r\n'.
La requête a été exécutée avec succès en 31 ms, mais ne renvoie aucun résultat.
#8 Re : ODBC » Requete -> ODBC -> Excel » 21/04/2011 10:55:28
J'ai essayé de retrouver le caractère en exportant les résultats au format CSV, je ne l'ai pas trouvé (dans PSP PAD, affichage en héxa, et fonction rechercher)
J'ai fais un programme c cherchant consécutivement les octets 0xc2 et 0c8c, il n'y sont pas.
Enfin, j'essaie d'utiliser la fonction regexp_replace, mais je n'y arrive , je ne sais pas m'en servir Comment passer en parametre mon code 0xC28C ??
#9 Re : ODBC » Requete -> ODBC -> Excel » 21/04/2011 08:31:34
Bonjour,
merci pour votre réponse,
Le caractère en erreur est 0x0c28c
Apres quelques recherches, je ne trouve que ca comme info :
U+008C c2 8c <control>
http://www.utf8-chartable.de/
Ce qui ne m'aide pas du tout
Je pensais trouver un caractère accentué ou un truc dans le style...
#10 ODBC » Requete -> ODBC -> Excel » 20/04/2011 18:23:31
- cébé
- Réponses : 16
Bonjour,
je souhaite automatiser la récupération de données de ma base PG SQL dans Excel.
Pour cela, je pensais utiliser OBDC, qui semble correctement installé, puisque je suis arrivé à me connecter à la base avec word en utilisant les fonctionnalités de publipostage.
Dans Excel, j'indique que je veux créer un tableau dynamique en choisissant une connexion ODBC me reliant à la base.
Le test de connexion est OK, mais lors de la récupération des données j'obtiens le message d'erreur suivant :
ERREUR : le caractère Ox--- du codage "UTF8" n'a pas d'équivalent dans "WIN1252";
Error while executing the query.
J'en déduis qu'il y a un problème de prototypage des données UTF8 en WIN1252 pour Excel....
Ma requête me renvoi bien des caractères accentués, je devais les convertir manuellement lorsque je passais par une requete avec pgAdmin, export CSV, import dans Excel.
Que puis je faire pour que les données soient correctement envoyées à Excel ?
J'ai trouvé des fonctions de configuration (\encoding par exemple), mais je ne vois ou placer cette commande puisque ODBC utilise une vue (une requête me poserait le même problème je pense?). Il semble pourtant possible de choisir le type de données du client
http://docs.postgresqlfr.org/8.4/multibyte.html
BD : Postgre SQL 8.4
Excel : 2007
Pilote ODBC pour PG : 8.04.01.00
merci par avance à toute âme charitable,
cébé.
#11 Re : Migration » Migration 8.3->8.4 forcée... » 17/03/2011 14:36:23
J'ai simplifié droits d'accès, ca marche, en attendant de remettre à plat la stratégie de sécurité 
#12 Re : Migration » Migration 8.3->8.4 forcée... » 17/03/2011 12:16:30
Je suis reparti du précédent, mais certaines écritures ne sont plus autorisées : style "ident=sameuser" pour la METHOD
En tout cas PG8.4 ne démarrait pas avec cette ligne (sur des règles local).
Côté utilisateur, non, je ne suis pas sur d'avoir remis tout le monde, mais je n'ai ... normalement ... besoin que de 2 utilisateurs. postgres et admin.
Ça m'a d'ailleurs montré une évidence, il faudra revoir ça et créer un utilisateur pour l'accès via l'intranet.
#13 Re : Migration » Migration 8.3->8.4 forcée... » 17/03/2011 12:08:49
Bonjour,
merci pour votre réponse, comme postée qques secondes plus tot que vous, j'ai réussit l'import dans webmin.
Je me bat maintenant avec ph_hba.conf pour autoriser les accès
#14 Re : Migration » Migration 8.3->8.4 forcée... » 17/03/2011 11:59:57
Je vais me répondre moi même : j'ai réussit à récupérer les données en faisant l'import depuis webmin, en créant la base et en demandant l'execution d'une requete SQL depuis le fichier .sql
cébé.
#15 Migration » Migration 8.3->8.4 forcée... » 17/03/2011 11:49:29
- cébé
- Réponses : 6
Bonjour,
j'ai lancé la migration de mon serveur ubuntu (d'entreprise) en version 10.
Je reconnais l'avoir fait à un moment ou le serveur était sous utilisé (peu d'utilisateurs) et je l'ai fait donc fait sans préparation
La migration s'est plus ou moins bien déroulée...
Mais pour postgres je suis bloqué : ubuntu obligeant à passer de PG 8.3 à 8.4.
J'ai heureusement par chance fait un export juste avant la migration avec pgadmin
Je souhaite donc maintenant recréer mes bases et importer mes données... car à priori ce n'est pas une simple migration de fichiers, les anciennes données sont perdues ? Je n'y accède plus en tout cas, et la version 8.3 est inaccessible, et PG 8.3 ne démarre pas.
J'en arrive au problème
J'ai réussit à lancer PGAdmin sur le serveur, et j'ai créé une base vierge.
Lorsque je lance la récupération de mon fichier (.sql), la commande COPY indique une erreur de syntaxe.
Les tables sont créées sans erreur.
Extrait du fichier là ou ca plante :
COPY activites (id_activites, type_activite, numero_activite, designation_activite, date_debut, date_fin, estouverte, id_secteurs, id_clients, date_cloture_administrative, date_cloture_technique, date_debut_garantie, date_fin_garantie, est_perdue, duree_garantie, est_archive, est_bilan, commentaire, est_garantie, est_auto_affect) FROM stdin;
1136 Affaire 0001 LOYER 2011-01-01 \N t 1 116 \N \N \N \N f 0 \N \N f t
Le plantage est lors de l'insertion de la première ligne.
L'erreur indiquée est une erreur de syntaxe, sur le premier caractère de 1136 ???
cébé.
#16 Re : Général » Table sans OIDS ni clef primaire » 08/10/2010 17:46:36
Bonjour,
et... MERCI !!!!
Je suis arrivé à recrééer une clef primaire (avec mes 3 colonnes).
Il ne me reste plus qu'à chercher les éventuelles données que j'ai ... "foirées"
Au moins, la base est à nouveau utilisable !
encore une grand merci !!
cébé.
#17 Re : Général » Table sans OIDS ni clef primaire » 08/10/2010 17:32:14
Petite précision, la base est en v8.3, sur serveur UBUNTU.
merci,
Cébé
#18 Général » Table sans OIDS ni clef primaire » 08/10/2010 17:20:28
- cébé
- Réponses : 3
Bonjour,
lors d'une opération de maintenance sur une table de mon intranet, j'ai supprimé la clef primaire sur 2 colonnes pour créer ensuite une clef primaire sur 3 colonnes.
Cela car il me fallait ajouter des données dans la troisième colonne et créer des doublons sur l'ancienne clef primaire.
Malheureusement, j'ai effectué cette opération sur une table sans OIDS (j'ai maintenant bien saisi à quoi cela servait...).
Lorsque j'essayais de modifier des données avec pgAdminIII, cela donnait quelques comportements bizarre... puisque le système ne pouvait plus identifier les lignes auxquelles je voulais accéder.
La création de la clef primaire n'est pas possible car j'ai des doublons sur ma table, même en mettant tous les champs dans la clef primaire.
Que puis je faire pour récupérer ma table fonctionnelle ?
Je pratique le SQL sans trop de soucis, mais cela n'étant pas mon activité principale, je ne vois pas comment traiter le problème
cébé.
nota : JC,tu es toujours par là ?
Pages : 1