SQL Mail RANT
-
Ok, this is a rant. I need to blow off some steam.
I would like to start by saying to Microsoft the following...
Dear Microsoft,
Your SQL Server product is absolutely fantastic. Since I first started working with SQL Server back in the pre 6.5 days, I have seen your product evolve into a true enterprise - level DBMS.
I have a few minor problems with the way things work, but most of them I can overlook and brush aside as "inconvinient" or a "minor nucience".
One issue I cannot brush aside is your implementation of SQL Mail. Quite simply, it sucks. Being tied to Microsoft Exchange / Outlook DESKTOP software for your email integration solution is a very poor decision at best.
I understand that you have reworked SQL Mail for the next version of SQL Server. Lets hope its more reliable than the current implementation. If it is, I would like to request that you release some kind of patch for SQL Server 2000.
-sincerely
Jeremy (Void) Brown
Database Administrator
Seriously, folks. It reeks. Here's the background on this...
About a year ago, I spent a week fooling around with SQL Mail and SQL Agent Mail to see if I could configure it to cache emails in the event that the exchange server was not availiable. The setup was a little weird, but it worked like a champ. Basically, all I did was set up some personal folders, set the delivery point to the personal folders in the profile, and entered some contacts in the personal folders contacts. I then unplugged my network cable and used both xp_sendmail and SQL Agent to send emails to my account.
When I plugged the network cable back in, the messages were delivered sucessfully. This was great! No longer was I tied to exchange server availiability! I could send e-mails from SQL Server to my hearts content, and when exchange server got around to making itself availiable, the messages would fire off. No more e-mails gettng lost in the vapor of network busyness and exchange outages.
Your friend and mine, Brian Kelley, has been after me for quite a while to write up my findings and submit them to SQL Server Central. Many of you have posted in the forums asking questions on how to do this. So this Monday, I finally made up my mind to write this article.
So I go to my desktop and fire up the control panel. I delete all the mail profiles. I then create my SQLMail profile and configure it for personal folders as described above. I test using xp_sendmail with the network connected. Yup, works fine.
Then I disconnect the network cable. Oh why, oh why do I tourture myself? Anyway, I go ahead and use xp_sendmail. Message sent... OK. Cool. Reconnect the network cable after about 5 minutes. Then I wait.
And wait.
Still waiting.
Nope. Drat. No-email.
Try the same test with SQL Agent Mail. Same results.
"What the heck?!", I said to myself. I stop SQL Server and SQL Server Agent. Restart. Mail pops into my inbox. "HUH???!"
So I wade in a bit more... I run the same test. I then run xp_stopmail. "SQL Mail Session Stopped". xp_startmail returns "SQL Mail Session Started". All of a sudden my workstation starts running like a dog. I run xp_stopmail, which takes about two minutes to stop the session again and POOF, the email pops into my inbox as soon as the mail session stops! xp_startmail again, and everything is normal.
I go to my SP2 SQL2K machine, and run the same test. Everything seems to work fine.
Now I haven't run a real detailed analysis (dll versions, MAPI versions, etc.) but from the outset it appears that SP3x, intentionally or unintentionally, changes the way that SQLMail works. In effect, it appears to reduce its functionality.
This is rediculous. Why do I have to be absolutely dependant on an e-mail server's 24/7 availiability in order to get email from SQL Server? At any time, exchange can be down. If it is, SQL Mail quits working correctly. This is completely unacceptable.
/rantoff
-
It's a fact.
I had experienced the same trouble last year. We called the Microsoft helpdesk for trouble shooting and it ended up with switching back to SP1 from SP2 Sql2000. They told us that they will refund back to us if it’s a problem. But I never heard anything with it after.
-
quote:
This is rediculous. Why do I have to be absolutely dependant on an e-mail server's 24/7 availiability in order to get email from SQL Server? At any time, exchange can be down. If it is, SQL Mail quits working correctly. This is completely unacceptable.Jeremy, you don't need the sleep. Just monitor 24/7 from your desktop. Take breaks only to raid the snack machine and shower.
But seriously, it's bad enough where we've gone to a job scheduler + Perl + SMTP that Jeremy had a huge hand in implementing. And we've learned our lesson with respect to SQLMail and applied it to other environments. We had a US$1M software package that did notifications using a client that run Outlook to fire off emails in the same way SQLMail does. Based on the lack of dependendability we've seen in SQLMail (even with Exchange is up... which is most of the time), we recommended engineering our own notification mechanism using the job scheduler + Perl + SMTP. The current solution with SQL Server 7.0 and 2000 isn't very workable.
K. Brian Kelley
http://www.truthsolutions.com/
Author: Start to Finish Guide to SQL Server Performance Monitoring
K. Brian Kelley
@kbriankelley -
I have to admit that I haven't had many issues, but when I do, they are very frustrating, especially for a simple process.
I'd agree, especially as my company is moving to Notes, that Outlook should not be required and actually any mail program should work fine with SQL. In a few places, I've installed ASPMail and used SP_OACREATE or an Active X DTS task to send items.
Steve Jones
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply