Discussion :

[Jason Chambers]

Bonjour,
utilisant
Windows Server 2012 R2
Postgresql 9.5 Beta
J'essaie d'importer des données dans plusieurs tables depuis des fichiers CSV sur un autre serveur.
J'ai un fichier BAT qui lance psql avec un fichier de commandes contenant une serie d'instructions de type \i nomdefichier.sql.

Ce syntaxe fonctionne correctement :

Code :

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

1
2
3
4
5
Copy matable  from '\\Serveur9\Donnees\mesdonnees.txt'
  WITH CSV 
     DELIMITER E'\t' 
     QUOTE AS '"'
     NULL AS '' ;

Mais je dois écrire le chemin en dur dans chacun de mes scripts SQL.

Et je voudrai éviter cela, puisque, l'année prochaine,
je sais que je vais changer le serveur qui héberge les données CSV ,
(et que pendant un certain temps le serveur actuel et le nouveau serveur vont cohabiter,).
Je me suis dit qu'il serait plus facile pour moi de créer un network ressource,
et le moment venu de switcher les serveurs,
je n'aurais plus que redéfinir ce ressource.

Je fais donc en ligne de commande

Code :

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

Net use S: \\Serveur9\Donnees /persistent:yes

et j'ai un nouveau disque S: qui pointe vers la source de mes données CSV.
Parfait.
Mais le syntaxe

Code :

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

1
2
3
4
5
Copy matable  from 'S:\mesdonnees.txt'
  WITH CSV 
     DELIMITER E'\t' 
     QUOTE AS '"'
     NULL AS '' ;

ne fonctionne pas.
Voici le message d'erreur :

psql:C:/pgstuff/imprt_1.sql:97: ERREUR: n'a pas pu ouvrir le fichier « S:\mesdonnees.txt » pour une lecture : No such file or directory

Mes questions :
Est-ce que ce fonctionnement est normal ? ( "By design" ?) dans la logique de l'interdiction des chemins relatifs avec COPY ? (Est-ce que un "disque réseau" est réellement relatif ?)
Ou est-ce que j'ai une faute syntaxe dans le style "escaped backslashes" ?
Ou est-ce que c'est un bug du 9.5 Beta ?
Ou encore autre chose ?

Merci d'avance,
Jason

[alassanediakite]

Salut
Vérifiez les droits d'accès à S:\
@+

[Jason Chambers]

Les droits seront identiques dans le deux cas puisque
1. S: est la même ressource que \\Serveur9\Donnees et
2. l'utilisateur est le même.
A moins qu'il y ait une subtilité que je n'ai pas encore compris.

Le syntaxe "URL" fonctionne, comme je l'ai indiqué dans mon post.
(Si c'était un problème de droits, ce syntaxe ne fonctionnerait pas.)
Le syntaxe "network ressource" ne fonctionne apparemment pas.

Ma question reste posée.

Jason

[alassanediakite]

Les droits seront identiques dans le deux cas puisque
1. S: est la même ressource que \\Serveur9\Donnees et

Je dirais plutôt "S: est une ressource pointant sur la ressource \\Serveur9\Donnees". Donc ils n'ont pas forcement les même attributs ni même les même valeurs.

2. l'utilisateur est le même.

Pas forcement!
psql peut lancer la commande \copy, dans ce cas, psq accède à S: avec les droits de celui qui lance le batch.
Mais si psql lance l'instruction copy, alors c'est le compte de postgresql qui accède à S:
@+

[Jason Chambers]

Ah !
et Hmmm !

je vais creuser de ce coté là.
Merci !