He venido a la solución de ese problema. No sé por qué funcionaría, pero nunca menos. :)Definitivamente se trata de seguridad.
Investigué que el Agente SQL se está ejecutando en nombre del usuario del dominio, digamos DOMINIO\Usuario Tiene un conjunto completo de derechos de administrador en el servidor (función de servidor 'sysadmin', etc.). El mismo SQL Server se está ejecutando bajo ese mismo usuario.
El paso del trabajo que contiene la llamada a sp_send_dbmail se ejecuta bajo el mismo DOMINIO\Usuario .
También lo he rastreado al ejecutar la parte de consulta de sp_send_dbmail intenta ejecutar exec xp_logininfo 'DOMAIN\User' para verificar con Active Directory si ese usuario está bien. Y sorpresa:algo definitivamente no está bien. Este cheque termina con:
Msg 15404, Level 16, State 19, Server SQLC002INS02\SQLC002INS02, Line 1
Could not obtain information about Windows NT group/user 'DOMAIN\User.', error code 0x2.
Eso, con cierta probabilidad, puede significar algo como que la contraseña de ese usuario haya caducado o que el usuario esté bloqueado o cualquier otra cosa desagradable para ese tipo.
Decidí que es arriesgado cambiar de usuario por Agente. Entonces llegué a enviar correo en nombre de 'sa', que tiene la misma función de servidor 'sysadmin' pero con autorización SQL y omite este paso de verificación de AD.
Parece que un usuario que se hace pasar por administrador le pide al administrador real que ejecute un código peligroso para él :)
Entonces, el código final de este trabajo es el primer y único paso similar a este:
execute as login = 'sa'
exec msdb.dbo.sp_send_dbmail
@profile_name = 'profile_name',
@recipients = '[email protected]',
@body = 'body',
@subject = 'subj',
--Parameters that refers to attached file
@attach_query_result_as_file = 1,
@query_result_header = 0,
@query_result_no_padding = 1,
@query = 'select 1',
@query_attachment_filename = 'test.csv'
revert
