January 24, 2019 at 8:28 am
mhtanner - Thursday, January 24, 2019 1:12 AMdb_send_dbmail returns a mailitem_id immediately (the email is queued to be sent later). Use that to read msdb.dbo.sysmail_mailitems and check sent_status at a later time (values 0-3 in my previous posting), rather than worrying about a unique subject. On our system it usually sends (or fails) within a second or two, but when there are problems can take up to a couple of minutes.
Exactly what I've usually seen as well. The optional output parameter of @mailitem_id from the stored procedure tends to get overlooked.
Sue
January 24, 2019 at 9:07 am
Okay, thanks! (Finally got the e-mail from my database!... where do they go when they get lost between my computer and gmail?) So I know the code works...
Guess I'll go play with it some more. But I think my problem is solved for now.
January 24, 2019 at 9:19 am
here's a scripts i actually put into views ie (GoodMail and FailMail) by toggling the WHERE statement; very handy for at a glance status of emails.
so i can review recent emails:
SELECT top 100
mail.send_request_date As SentDate,
sent_status As Reason,
err.[description],
mail.*
FROM [msdb].[dbo].[sysmail_allitems] mail
inner join [msdb].[dbo].[sysmail_event_log] err
ON err.mailitem_id = mail.mailitem_id
WHERE mail.sent_status <> 'sent'
order by mailitem_id desc
Lowell
January 24, 2019 at 10:39 am
In addition to Lowell's query showing you the details of messages that have errored, there is also a query you can run to see items that are stuck in an UNSENT state, and wouldn't show up in sysmail_event_log:SELECT * FROM dbo.sysmail_unsentitems;
Note: this does just query sysmail_allitems behind the scenes.
Viewing 4 posts - 16 through 18 (of 18 total)
You must be logged in to reply to this topic. Login to reply