Il me semble que vous n'attendez pas de code SQL dans la réponse à votre question. L'aspect principal de votre question est l'aspect sécurité. Que devez-vous faire pour implémenter votre exigence sans sysadmin privilèges et sans nouvelle faille de sécurité ? C'est ta vraie question je pense.
Je vois au moins 3 façons de résoudre votre problème. Mais tout d'abord, une brève explication de la raison pour laquelle les privilèges sysadmin existent dans toutes les solutions basées sur les procédures stockées étendues . Procédures stockées étendues telles que xp_cmdshell sont très vieux. Ils existaient au moins avant SQL Server 4.2, le premier Microsoft SQL Server fonctionnant sous le premier Windows NT (NT 3.1). Dans l'ancienne version de SQL Server, je n'avais pas de restriction de sécurité pour exécuter de telles procédures, mais plus tard, on a fait de telles restrictions. Il est important de comprendre que tous les produits à usage général procédures qui permettent de démarrer n'importe quel processus sous le compte SQL Server comme xp_cmdshell et sp_OACreate doit avoir un administrateur système restriction des privilèges. Uniquement axé sur la tâche les procédures avec une zone d'utilisation claire et des autorisations basées sur les rôles peuvent résoudre le problème sans faille de sécurité. Voici donc les 3 solutions que j'ai promises auparavant :
- Vous créez un nouveau compte SQL sur votre serveur SQL avec sysadmin privilèges. Ensuite, vous créez une procédure stockée qui utilise certaines des procédures stockées étendues comme
xp_cmdshellousp_OACreateet mettre en œuvre techniquement vos exigences (exporter certaines informations dans un fichier CSV). En ce qui concerne EXÉCUTER COMME Clause (voir http://msdn.microsoft.com/en-us/ bibliothèque/ms188354.aspx ) vous configurez la procédure stockée créée afin qu'elle s'exécute sous le compte avec sysadmin privilèges. Vous déléguez l'exécution de cette procédure à des utilisateurs avec un certain rôle SQL, pour être plus flexible du côté de la délégation de permission. - Vous pouvez utiliser les procédures stockées CLR au lieu de
xp_cmdshelletsp_OACreate. Vous devez également utiliser des autorisations basées sur les rôles sur la procédure créée. - L'utilisateur final n'appelle directement aucune procédure stockée SQL que vous créez. Il existe un logiciel (comme le service WCF ou un site Web) qui appelle votre procédure stockée SQL. Vous pouvez implémenter l'exportation vers un fichier CSV dans ce logiciel et non dans une procédure stockée SQL.
Dans toutes les manières de mise en œuvre, vous devez définir exactement où vous conserverez le mot de passe du compte avec lequel vous accédez au système de fichiers. Il existe différentes options qui s'offrent à vous, toutes avec des avantages et des inconvénients correspondants. Il est possible d'utiliser l'emprunt d'identité pour autoriser l'accès au système de fichiers avec le compte de l'utilisateur final. La meilleure façon dépend de la situation que vous avez dans votre environnement.
