Créer un fichier txt via SQL Server
Fermé
Bonjour,
Je souhaiterais créer un fichier txt via une procédure stockée écrite sous SQL Server 7. Ce fichier me permettra d'y écrire toutes les erreurs produites lors de l'exécution de la procédure.
Est ce possible, car je n'ai trouvé aucune fonction TRANSACT SQL de gestion de fichier ?
De même dans ma procédure, j'aurais besoin de vérifier la présence d'un fichier excel avant de faire un bulk insert.
Merci de votre aide :)
Scabo
Je souhaiterais créer un fichier txt via une procédure stockée écrite sous SQL Server 7. Ce fichier me permettra d'y écrire toutes les erreurs produites lors de l'exécution de la procédure.
Est ce possible, car je n'ai trouvé aucune fonction TRANSACT SQL de gestion de fichier ?
De même dans ma procédure, j'aurais besoin de vérifier la présence d'un fichier excel avant de faire un bulk insert.
Merci de votre aide :)
Scabo
A voir également:
- Créer un fichier txt via SQL Server
- Créer un compte google - Guide
- Creer un fichier .bat - Guide
- Comment créer un groupe whatsapp - Guide
- Comment ouvrir un fichier epub ? - Guide
- Comment réduire la taille d'un fichier - Guide
2 réponses
xp_cmdshell permet d'exécuter n'importe quelle commande système du moment que tu as un accès au serveur SQL.
Ce qui veut dire que si quelqu'un parviens se loguer au serveur SQL, ou à avoir les droits sur la procédure stockée, il pourra accéder au niveau en dessous (le système).
Chez nous (serveur d'eCommerce d'une grosse boites, quelques millions d'euros de C.A.) ça nous est interdit par l'équipe sécurité, et nous ne voulons pas l'utiliser non plus.
Et en plus, le lancement d'une commande shell à partir du serveur SQL peut potentiellement planter le serveur SQL lui-même...
L'idéal, c'est de placer les applications sur un autre serveur.
Dans ton cas, voilà ce que j'aurais fait:
La procédure stockée écrit les erreurs dans une table de log, et cette table est régulièrement lue (soit exportée par un package DTS, soit interrogée par requête SQL).
Ainsi, tu n'as pas besoin d'exécuter des programmes directement sur le serveur SQL.
Ce qui veut dire que si quelqu'un parviens se loguer au serveur SQL, ou à avoir les droits sur la procédure stockée, il pourra accéder au niveau en dessous (le système).
Chez nous (serveur d'eCommerce d'une grosse boites, quelques millions d'euros de C.A.) ça nous est interdit par l'équipe sécurité, et nous ne voulons pas l'utiliser non plus.
Et en plus, le lancement d'une commande shell à partir du serveur SQL peut potentiellement planter le serveur SQL lui-même...
L'idéal, c'est de placer les applications sur un autre serveur.
Dans ton cas, voilà ce que j'aurais fait:
La procédure stockée écrit les erreurs dans une table de log, et cette table est régulièrement lue (soit exportée par un package DTS, soit interrogée par requête SQL).
Ainsi, tu n'as pas besoin d'exécuter des programmes directement sur le serveur SQL.