Gift Peddie (5/27/2010)
This then runs at a particular interval as a scheduled task and I keep our Exchange Admin from breathing down my neck.
This relates to what I was saying about Enterprise restrictions these Exchange admins have created business for Google because Google let us run Asp.net System.NET code when Enterprise Exchange Admins and Hotmail were blocking our code. Today Google GMail pro is used by many small businesses. Microsoft is fighting back Exchange online Admins are Microsoft employees.
I dunno, I can run any code I want. If I was to take my perfectly acceptable sql solution, export the already generated email list to another application/server to sort out and then manage the interim code, I sure as hell would want it in house rather than rely on 3rd party.
OK, google lets you run ASP code. So, your SQL job that is already run via SQL to generate other info, rather than using built in SQL Server mail functionality will what? Generate a temp table of recipients in time for a separate sheduled ASP task to read the table and communicate with google to create a sender list to send a mail?
Technically speaking I can actually create a temporary mailing group in exchange directly from SQL server but why would I want to.
"Also, on the exchange admin breathing down my neck" issue, that is only going to be a problem with small businesses who can't afford <exagerate>16 processor, quad core 64GB Exchange servers and TB leased lines</exagerate>. I know for a fact that paying for hardware, OS and Software it is a hell of a lot cheaper for us to do it in house with MS Exchange even over 2 years than it is to go corporate hosted.Again though, that is off topic for this post.
If you are sending a lot of emails via SQL Server, and the mail server balks a bit here is one suggestion as to how to batch it.
I also submitted an alternative batching solution. It may bo good, it may not be.
It would be nice to see more comments on the actual area of toppic (how to batch it)
I have not yet had a chance to do tests on the code for performance and look at it as a whole but intend to. I submitted my version as an alternative but it may be awful in comparison. It certainly has the flaw that the batch size is limited by an unknown amount depending on average email length in batch.
It's a good article, Let's discuss the article rather than the mirriad ways of sending email.
Change is inevitable... Except from a vending machine.