Sono venuto a risolvere il problema. Non so perché dovrebbe funzionare, ma mai di meno. :) Si tratta sicuramente di sicurezza.
Ho verificato che SQL Agent è in esecuzione per conto dell'utente del dominio, ad esempio DOMAIN\User .Ha un set completo di diritti di amministratore sul server (ruolo del server 'sysadmin', ecc.). SQL Server stesso è in esecuzione con lo stesso utente.
La fase del lavoro che contiene la chiamata a sp_send_dbmail viene eseguito sotto lo stesso DOMINIO\Utente .
Inoltre l'ho tracciato durante l'esecuzione della parte della query di sp_send_dbmail tenta di eseguireexec xp_logininfo 'DOMAIN\User' per verificare con Active Directory se quell'utente è OK. E sorpresa:qualcosa non va assolutamente bene. Questo controllo 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.
Questo, con una certa probabilità, può significare qualsiasi cosa sulla password di quell'utente è scaduta o l'utente è bloccato o qualsiasi altra cosa non piacevole per quel ragazzo.
Ho deciso che è rischioso cambiare utente per Agent. Quindi arrivo a inviare posta per conto di "sa" che ha lo stesso ruolo del server "amministratore di sistema" ma l'autorizzazione SQL e omette questo passaggio di controllo AD.
Sembra un utente che finge di essere amministratore per chiedere al vero amministratore di eseguire codice pericoloso per lui :)
Quindi il codice finale di questo lavoro è il primo e l'unico passaggio simile a questo:
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
