Parece-me que você não está esperando por um código SQL na resposta à sua pergunta. O principal aspecto de sua pergunta é o aspecto de segurança. O que você deve fazer para implementar seu requisito sem sysadmin privilégios e sem uma nova brecha de segurança? Esta é a sua verdadeira pergunta, eu acho.

Vejo pelo menos 3 maneiras de resolver seu problema. Mas, antes de tudo, uma breve explicação por que os privilégios de sysadmin existem em todas as soluções baseadas em Extended Stored Procedures . Procedimentos armazenados estendidos como xp_cmdshell são muito velhos. Eles existiam pelo menos antes do SQL Server 4.2, o primeiro Microsoft SQL Server executado no primeiro Windows NT (NT 3.1). Na versão antiga do SQL Server não havia restrição de segurança para executar tais procedimentos, mas posteriormente fazia-se tais restrições. É importante entender que todos os propósitos gerais procedimentos que permitem iniciar qualquer processo na conta do SQL Server como xp_cmdshell e sp_OACreate deve tem administrador de sistema restrição de privilégios. Apenas um orientado a tarefas procedimentos com uma área clara de uso e permissões baseadas em função podem resolver o problema sem uma falha de segurança. Então, estas são as 3 maneiras de solução que prometi antes:

• Você cria uma nova conta SQL em seu servidor SQL com sysadmin privilégios. Em seguida, você cria um procedimento armazenado que usa alguns dos Procedimentos armazenados estendidos como xp_cmdshell ou sp_OACreate e implementar tecnicamente seus requisitos (exportar algumas informações para um arquivo CSV). Com relação a EXECUTAR COMO Cláusula (consulte http://msdn.microsoft.com/en-us/ library/ms188354.aspx ) você configura o procedimento armazenado criado para que ele seja executado na conta com sysadmin privilégios. Você delega a execução deste procedimento a usuários com alguma função SQL, para ser mais flexível do lado da delegação de permissão.
• Você pode usar procedimentos armazenados CLR em vez de xp_cmdshell e sp_OACreate . Você também deve usar permissões baseadas em função no procedimento criado.
• O usuário final não chama diretamente nenhum procedimento armazenado SQL que você cria. Existe um software (como o serviço WCF ou um Web Site) que chama seu procedimento armazenado SQL. Você pode implementar a exportação para arquivo CSV dentro deste software e não dentro de qualquer procedimento armazenado SQL.

Em todas as formas de implementação, você deve definir exatamente onde guardará a senha da conta com a qual você acessa o sistema de arquivos. Existem diferentes opções que você tem, todas com vantagens e desvantagens correspondentes. É possível usar a representação para permitir o acesso ao sistema de arquivos com a conta do usuário final. A melhor maneira depende da situação que você tem em seu ambiente.