June 20, 2013 at 10:36 pm
Maybe - when email is sent successfully from management studio the last_mod_user entry in sysmail_log is NT AUTHORITY\NETWORK SERVICE and when it fails after invoking sql agent job that entry is sa.
June 20, 2013 at 11:04 pm
Hi,
could it be a access issue? Sql service and agent are running under different accounts?
June 20, 2013 at 11:12 pm
This post was a reply to your post:
Maybe - when email is sent successfully from management studio the last_mod_user entry in sysmail_log is NT AUTHORITY\NETWORK SERVICE and when it fails after invoking sql agent job that entry is sa.
We are a small company, no dba. Not sure how to resolve account issue if that is it.
Thanks.
June 20, 2013 at 11:24 pm
I suggest to change 'sa' account to the account what you are running in ssms in sql job. Let us see it solves the issue.
June 21, 2013 at 10:11 am
Changed both server and agent to run as Network Service. Same results. Changed both server and agent to run under same network account name & password. Same results.
Thank you.
June 24, 2013 at 10:57 am
Dug further and found this error:
The server principal "xxxx" is not able to access the database "yyyy" under the current security context.
Where xxxx is the SQL Server Agent account. Added that account specifically with sa privileges and fixed the problem. Weird we had to do that just for jobs that have query results as an attachment because as mentioned all others were working fine.
Thank you for your replies.
June 24, 2013 at 1:01 pm
Actually that does make sense, whatever was trying to connect to that other database lacked sufficient rights to access the database..
CEWII
Viewing 7 posts - 16 through 21 (of 21 total)
You must be logged in to reply to this topic. Login to reply