Discussion :

[pyrrhias]

Bonjour,

Je travaille sur un serveur mutualisé OVH et je souhaite importer un fichier csv, avec délimiteur '';'', dans une base Postgresql. J'ai copié le fichier csv dqns le répertoire www et j'ai lancé une commande de type SQL COPY FROM '/www/wp-includes/xxxxxx/liste_produits.csv' with delimiter ';' . Cela ne fonctionne est-ce quelqu'un a une suggestion ? J'ai bien sur fait toute sorte d'essai. Merci d'avance

[CetTer]

Il peut y avoir plusieurs sources à ce problème, entre autres:
-les permissions sur le fichier (l'user "postgres" peut-il y accéder)?
-directive "quote" manquante, ce qui est problématique si les données texte contiennent le délimiteur (personnelement je préfère recourir à "\t" plutôt que des séparateur qui appartiennent à la langue naturelle)
-format d'encodage (UTF-8, Latin1, etc...) différent entre le serveur Postgresql et le fichier, le plus rapide est alors de re-sauvergarder le fichier dans un éditeur de type notepad++ dans le format d'encodage des tables.
etc...

[Invité]

Bonsoir,

@CetTer sur un hebérgement OVH il n'y a pas d'accès à l'utilisateur postgres comme cela pourrait être sur une solution VPS.

Le problème viens sûrement du fait que sur un hébergement mutualisé, OVH*le répertoire www n'est pas stocker à côté (sur la même machine) que la base de donnée ; ça explique le soucis de lancement de la commande sql qui ne trouvera jamais le chemin du script à lancer.

D'après moi, le plus simple reste de charger le csv sur un base dédié et de transférer un dump , sur un schéma différent si besoin.

[mister3957]

Si ton fichier CSV est accessible via le réseau, tu peux peut-être utiliser le

Code :

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

1
2
 
COPY FROM PROGRAM 'curl http://url_vers_fichier_csv.csv'

?

[Invité]

OVH donne des accès pour les bases MySql, je viens de tomber sur la doc ici, mais malheureusement pas pour postgres.

Il parle d'un accès ssh mais il n'est visiblement pas inclus dans mon offre.

Code :

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

1
2
ssh monuser@ip_serveur_ftp 
ssh: connect to ………… port 22: Connection refused

[mister3957]

Mais tu peux te connecter à ta base PostgreSQL non ? Avec pgAdmin par exemple.

Ensuite tu exécutes des requêtes en prenant en compte que le process tourne sur une machine, et si tu n'as pas la possibilité d'accéder aux fichiers physiquement, tu peux les rendre accessibles en http et utiliser COPY FROM PROGRAM ainsi que curl pour récupérer le fichier et l'intégrer.

[CetTer]

Sinon du piping via la console shell pourrait fonctionner vu que "COPY' accède à stdin.

Code :

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

1
2
 
cat myfile | psql -c "COPY mytable (name, description, text) FROM stdin

(mais il faut que le mot de passe soit dans le fichier .pgpass pour que sa saisie n'interfère pas avec le flux)

[Invité]

Mais tu peux te connecter à ta base PostgreSQL non ? Avec pgAdmin par exemple.

Hélas non je ne crois pas, il y a juste phppgadmin et il n'y a pas d'import de CSV avec cette interface.

C'est pas terrible, j'imagine que les choses vont évoluer chez OVH, la solution étant relativement récente.

[pyrrhias]

Bonjour,

J'ai essaye COPY FROM PROGRAM 'curl
http://xxxxx/yyyyy/liste_produits.csv' et j'obtiens :

Erreur SQL :

ERREUR: erreur de syntaxe sur ou près de « FROM »
LINE 1: SELECT COUNT(*) AS total FROM (COPY FROM PROGRAM 'curl http:...

Je vais essayer les autres solutions proposees, mais je n'ai pas tout compris.

Merci


^

[pyrrhias]

J'ai ouvert mon fichier csv avec notpad++ et j'ai sauve le fichier avec un encodage UTF8 et la commande COPY FROM '/www/wp-includes/xxxxx/liste_produits_UTF8.csv' with delimiter ';' a échoué. Je crois que je vais abandonne et revenir a MYSQL

[pyrrhias]

''D'après moi, le plus simple reste de charger le csv sur un base dédié et de transférer un dump , sur un schéma différent si besoin.''

Je ne comprends pas

Tu parles d'une base MYSQL ?

Je cree une base MYQL avec mon fichier CSV et ensuite je transfere un dump vers Postgesql ?

[pyrrhias]

J'ai importe mon fichier CSV sans emcombre dans une base MYSQL. J'exporte le code SQL et j'execute ce code dans phpPgAdmin et j'obtiens une erreur ici :

CREATE TABLE IF NOT EXISTS `TABLE 1` (

Quelqu'un a t-il une suggestion ?

[Invité]

Non je parlais de faire sur une base Postgres tampon pour créer le dump ; quant au message d'erreur il suffit de ne pas cocher (ou décocher) la case « Paginer les résultats » dans l'interface phppgadmin.

[pyrrhias]

Ce n'est pas claire pour moi ''base tampon postgresql''. Je ne vois pas justement comment créer cette base postgresql à partir du fichier CSV. Quelque chose doit m'échapper.
Je compte clôturer cette discussion car tout est si simple avec mysql.

[Invité]

Désolé si je ne suis pas clair quand je parle d'une base tampon ; je pense à quelque chose en locale (en tous cas pas hébergé chez OVH).

Pour ce qui est d'être plus simple avec MySql ; je dirais que la solution d'OVH n'est pas encore aussi aboutie côté Postresql qu'elle peut l'être pour la solution MySql.
Ma comparaison entre les deux SGBD se résume par le fait que si l'un n'était pas soutenu par Oracle il aurait disparu (c'est que mon avis ).


Maintenant si vous avez commencé votre application ou page web sur votre hébergement, c'est à cet endroit que vous devriez créer le formulaire de chargement de votre CVS.

[estofilo]

J'ai importe mon fichier CSV sans emcombre dans une base MYSQL. J'exporte le code SQL et j'execute ce code dans phpPgAdmin et j'obtiens une erreur ici :

CREATE TABLE IF NOT EXISTS `TABLE 1` (

Quelqu'un a t-il une suggestion ?

Les apostrophes inversées ou backticks autour du nom de table ne sont supportées que par MySQL.
Le standard SQL indique que c'est les guillemets qui doivent être utilisés pour ça, et c'est la règle que suit PostgreSQL.

Ceci dit, le plus simple est de ne pas mettre d'espace au milieu d'un nom de table, même si c'est syntaxiquement valide, parce que c'est pénible à l'usage.
En utilisant uniquement [a-z_0-9] et pas de mots réservés pour tous les identifiants, on n'a jamais besoin de guillemets.

[al1_24]

Le standard SQL indique que c'est les guillemets qui doivent être utilisés pour ça, et c'est la règle que suit PostgreSQL.

Précision : il s'agit des guillemets doubles ", les guillemets simples ' étant utilisés pour encadrer les chaines de caractères.

Ceci dit, le plus simple est de ne pas mettre d'espace au milieu d'un nom de table, même si c'est syntaxiquement valide, parce que c'est pénible à l'usage.
En utilisant uniquement [a-z_0-9] et pas de mots réservés pour tous les identifiants, on n'a jamais besoin de guillemets.