Version imprimable
Bonjour,
J'ai une PL/SQL qui créé un fichier sous un environnement UNIX : cette PL/SQL est exécutée via un script UNIX sous l'utilisateur toto mais le fichier en sortie appartient à l'utilisateur ORACLE.
Or, j'ai besoin de modifier ce fichier ensuite dans mon script UNIX et l'utilisateur toto n'a pas les droits.
Y-a-t-il une possibilité via la PL/SQL de forcer le propriétaire ou les droits du fichier?
Merci.
Cordialement.
selon la document Oracle
Vous pouvez toutefois faire un petit quelque chose en stored procedure Java qui irait modifier la permission du fichier..Citation:
On UNIX systems, a file created by the FOPEN function has as its owner the owner of the shadow process running the instance. In the normal case, this owner is oracle. Files created using FOPEN are always writable and readable using the UTL_FILE subprograms, but non-privileged users who need to read these files outside of PL/SQL might need their system administrator to give them access.
Merci pour cette réponse.
J'ai déjà essayé en java mais les droits ne se modifient pas si je ne suis pas propriétaire du fichier, ou alors il y a quelque chose qui m'échappe.
Je vais creuser de nouveau de ce côté là.
Je pense qu'ne fois le fichier crée vous pouvez exécuter un script batch sur le serveur via dbms_scheduler pour changer les droits sur le fichier en question.
effectivement, mais si le fichier doit être traiter avant que le schéduleur passe, une procédure stocké en java va très bien faire l'affaire, il suffirait d'appeler une commande shell qui irait modifier les droits du fichier directement.
Le scheduler passe tout de suite. A la limite vous attendez un ou deux secondes dans votre traitement.Citation:
Envoyé par dbaste
Normalement la procédure stocké Java devrait être soumise aux même restrictions que le package UTL_FILE, avez vous testé ?
Pourquoi modifier l'original en place : vous pouvez le lire et produire un nouveau fichier qui sera utilisé par l'étape suivante…Citation:
Envoyé par Michalak
Merci pour toutes vos réponses.
La procédure java qui exécute un chmod en runtime ne fonctionne effectivement pas : mêmes contraintes sur les droits.
J'avais une contrainte sur le nom du fichier qui devait resté le même.
Je m'en suis donc sorti en java en passant par un fichier temporaire puis un delete du fichier d'origine et rename du fichier temporaire et là, il n'y a pas de contraintes.