Click here to monitor SSC
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Email Formatted HTML Table with T-SQL


Email Formatted HTML Table with T-SQL

Author
Message
anil.narla
anil.narla
Forum Newbie
Forum Newbie (3 reputation)Forum Newbie (3 reputation)Forum Newbie (3 reputation)Forum Newbie (3 reputation)Forum Newbie (3 reputation)Forum Newbie (3 reputation)Forum Newbie (3 reputation)Forum Newbie (3 reputation)

Group: General Forum Members
Points: 3 Visits: 9
Does this work when those e-mails are opened using outlook 2007 or later versions?
Aleksandr Furman
Aleksandr Furman
SSC-Addicted
SSC-Addicted (462 reputation)SSC-Addicted (462 reputation)SSC-Addicted (462 reputation)SSC-Addicted (462 reputation)SSC-Addicted (462 reputation)SSC-Addicted (462 reputation)SSC-Addicted (462 reputation)SSC-Addicted (462 reputation)

Group: General Forum Members
Points: 462 Visits: 114
This subject is very dear to my heart - I had to do so many projects that send emails to customers. One thing I always do is create HTML templates with my own tags inside. I usually have one template for the body and second for the line. This gives me ability to have multiple versions of the same email in different languages for example. Then at run time, driven by data I select appropriate template with a series of simple replace statements plug in data in place of my tags. and send it out.
I remember one project were I had 10 variations of email in 3 different languages, 30 total and was all handled in one procedure.
Aleksandr Furman
Aleksandr Furman
SSC-Addicted
SSC-Addicted (462 reputation)SSC-Addicted (462 reputation)SSC-Addicted (462 reputation)SSC-Addicted (462 reputation)SSC-Addicted (462 reputation)SSC-Addicted (462 reputation)SSC-Addicted (462 reputation)SSC-Addicted (462 reputation)

Group: General Forum Members
Points: 462 Visits: 114
I've never had a problem with any of the email clients. Simple HTML is recognized by all of them.
Mike Dougherty-384281
Mike Dougherty-384281
Old Hand
Old Hand (318 reputation)Old Hand (318 reputation)Old Hand (318 reputation)Old Hand (318 reputation)Old Hand (318 reputation)Old Hand (318 reputation)Old Hand (318 reputation)Old Hand (318 reputation)

Group: General Forum Members
Points: 318 Visits: 944
Are we solving the problem right?
Are we solving the right problem?

Jeff asked why use xp_cmdshell to get to a third-party tool & suggested db_sendmail: depending on your environment, the answer to that first question is either "No" or "Right enough" Smile

I wonder if composing html <table>s and emailing them is the right way to share content.
(aside from the pretty/ugly formatting of inline style workarounds for various capabilities of mail client(s) such as gmail stripping style tags and even inline attributes google decided aren't appropriate for your email or Outlook 2007/2010 using Word to render emails)

If the data is meant to be further consumed, the html table is somewhat klunky. If the data is meant to be looked at, there is too much requirement for 'pretty' to make emailed tables a robust solution. If the data is meant to be proof that something else happened, does it need to provide so much detail (and cost the overhead to get all that detail, formatted, etc.)?

If the data were staged for consumption by a data-query in Excel (for example) the analyst using it would be able to easily further transform via charting/pivoting/filtering, etc. If reporting services (either MS, or 3rd party such as Crystal Reports/Crystal Solutions) generates the 'pretty' version to a PDF - that could be mailed/attached/referenced. Another option might be to simply render the data to html via a web service: properly executed CSS can make a nice view for direct human eyes-on or the semantically correct table can be consumed by Excel's html table import (or googledocs html scraping equivalent)

Another consideration is the amount of content we _can_ get from a query may be much more than we _should_ put in an email. I know, nobody intends to put 30k rows of data in an email... When we built and tested there was only 200 rows in the table... 3 years later we're causing grief to the email administrator when we're storing an html version of the day's snapshot in 12 email recipient's inbox. (and 10 of those recipients keep everything we've ever mailed in "archive" folders on the email server) I'm not sure if this qualifies as Database Backup, but you can see how well it scales. Smile
Jeff Moden
Jeff Moden
SSC-Forever
SSC-Forever (45K reputation)SSC-Forever (45K reputation)SSC-Forever (45K reputation)SSC-Forever (45K reputation)SSC-Forever (45K reputation)SSC-Forever (45K reputation)SSC-Forever (45K reputation)SSC-Forever (45K reputation)

Group: General Forum Members
Points: 45277 Visits: 39934
SQL-DBA (6/20/2013)
Jeff Moden (6/19/2013)
I don't believe you'll find anyone more pro-xp_CmdShell or pro_BCP than myself but I can't figure out why you bothered with either for this task since sp_SendDBMail could have easily handled this task. And having to install a 3rd party piece of shareware on a server certainly doesn't make for a "T-SQL Only" project, IMHO.

Why didn't you just use sp_SendDBMail which can take a 2GB VARCHAR(MAX) body with the custom HTML formatting from your article?



Thanks for the feedback Jeff!

Basically, I think you are right. I should have written the article with a more modern twist. The practical reason is that I wear many different hats so I end up using Blat for SysAdmin tasks, AD notifications, sending log files, etc. And I was using Blat with SQL Server 7.0. It is just an old habit that works so I haven't changed it.


Ah! I get that. Thanks, for the feedback, Steve. I still use CDOSYS for my DBA emails for couple of reasons not the least of which is that sp_SendDBMail didn't allow for a specific FROM (fixed in 2012, IIRC) without taking the time to setup a different profile. I also work on servers that don't (and won't for one reason or another) have email setup where it comes in might handy for the generation of "Morning Reports" on the server status.

--Jeff Moden

RBAR is pronounced ree-bar and is a Modenism for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
Although they tell us that they want it real bad, our primary goal is to ensure that we dont actually give it to them that way.
Although change is inevitable, change for the better is not.
Just because you can do something in PowerShell, doesnt mean you should. Wink

Helpful Links:
How to post code problems
How to post performance problems
Forum FAQs
Dave Vroman
Dave Vroman
SSC-Enthusiastic
SSC-Enthusiastic (163 reputation)SSC-Enthusiastic (163 reputation)SSC-Enthusiastic (163 reputation)SSC-Enthusiastic (163 reputation)SSC-Enthusiastic (163 reputation)SSC-Enthusiastic (163 reputation)SSC-Enthusiastic (163 reputation)SSC-Enthusiastic (163 reputation)

Group: General Forum Members
Points: 163 Visits: 716

Because of PCI compliance, both xp_cmdshell and db_sendmail are disabled on our database servers. I needed to get some of my tasks to send email to me so I used CDOSYS.
The script supports both text and HTML email formats.


Here is the base code:



CREATE PROCEDURE usr_sp_send_cdosysmail
@From_Addr VARCHAR(500) ,
@To_Addr VARCHAR(500) ,
@Subject VARCHAR(500) ,
@Body VARCHAR(8000) ,
@SMTPserver VARCHAR(25) = 'localhost',
@BodyType VARCHAR(10) = 'textbody'
AS

DECLARE @imsg INT
DECLARE @hr INT
DECLARE @source VARCHAR(255)
DECLARE @description VARCHAR(500)

EXEC @hr = sp_oacreate 'cdo.message', @imsg out
EXEC @hr = sp_oasetproperty @imsg, 'configuration.fields("http://schemas.microsoft.com/cdo/configuration/sendusing").value','2'
EXEC @hr = sp_oasetproperty @imsg, 'configuration.fields("http://schemas.microsoft.com/cdo/configuration/smtpserver").value', @SMTPserver
EXEC @hr = sp_oamethod @imsg, 'configuration.fields.UPDATE', NULL

EXEC @hr = sp_oasetproperty @imsg, 'to', @To_Addr
EXEC @hr = sp_oasetproperty @imsg, 'from', @From_Addr
EXEC @hr = sp_oasetproperty @imsg, 'subject', @Subject

-- If you are using html e-mail, use 'htmlbody' instead of 'textbody'.
EXEC @hr = sp_oasetproperty @imsg, @BodyType, @Body
EXEC @hr = sp_oamethod @imsg, 'send', NULL

EXEC @hr = sp_oadestroy @imsg


How To Call The Procedure:



EXEC usr_sp_send_cdosysmail
@From_Addr='myaddr@myurl.com',
@to_Addr ='youraddr@yoururl.com',
@subject ='Formatted email from SQL',
@body ='<B>Test Email From SQL</B>
Please Ignore this <FONT COLOR=red>email.</FONT>',
@smtpserver ='localhost',
--
@bodytype ='HTMLBody'
-- @bodytype ='textbody'


Jeff Moden
Jeff Moden
SSC-Forever
SSC-Forever (45K reputation)SSC-Forever (45K reputation)SSC-Forever (45K reputation)SSC-Forever (45K reputation)SSC-Forever (45K reputation)SSC-Forever (45K reputation)SSC-Forever (45K reputation)SSC-Forever (45K reputation)

Group: General Forum Members
Points: 45277 Visits: 39934
Mike Dougherty-384281 (6/20/2013)
Are we solving the problem right?
Are we solving the right problem?

Jeff asked why use xp_cmdshell to get to a third-party tool & suggested db_sendmail: depending on your environment, the answer to that first question is either "No" or "Right enough" Smile

I wonder if composing html <table>s and emailing them is the right way to share content.
(aside from the pretty/ugly formatting of inline style workarounds for various capabilities of mail client(s) such as gmail stripping style tags and even inline attributes google decided aren't appropriate for your email or Outlook 2007/2010 using Word to render emails)

If the data is meant to be further consumed, the html table is somewhat klunky. If the data is meant to be looked at, there is too much requirement for 'pretty' to make emailed tables a robust solution. If the data is meant to be proof that something else happened, does it need to provide so much detail (and cost the overhead to get all that detail, formatted, etc.)?

If the data were staged for consumption by a data-query in Excel (for example) the analyst using it would be able to easily further transform via charting/pivoting/filtering, etc. If reporting services (either MS, or 3rd party such as Crystal Reports/Crystal Solutions) generates the 'pretty' version to a PDF - that could be mailed/attached/referenced. Another option might be to simply render the data to html via a web service: properly executed CSS can make a nice view for direct human eyes-on or the semantically correct table can be consumed by Excel's html table import (or googledocs html scraping equivalent)

Another consideration is the amount of content we _can_ get from a query may be much more than we _should_ put in an email. I know, nobody intends to put 30k rows of data in an email... When we built and tested there was only 200 rows in the table... 3 years later we're causing grief to the email administrator when we're storing an html version of the day's snapshot in 12 email recipient's inbox. (and 10 of those recipients keep everything we've ever mailed in "archive" folders on the email server) I'm not sure if this qualifies as Database Backup, but you can see how well it scales. Smile


It really does depend. I can't answer for anyone else but I'm a mostly a data-troll and, as a result, don't know how to make a web service and will probably never learn how. I agree that such a thing or the use of Crystal Reports, SSRS, or any of a dozen other methods would probably be the best thing to do for "production runs" but simple embedded HTML created by a stored procedure works quickly and under my full control without much overhead for things like the morning reports that I have to send to people in IT.

I absolutely agree about the email thing where people keep stuff forever and that HTML formatting is worse than clunky if the data is to be consumed electronically. That's definitely something to consider before building such a repetative email regardless of method used to build it. Even something as simple as large TSV files (for import to Excel, for example) as attachments should be avoided in most cases because of such people. Far better to save it as a "managed" file somewhere that people can get to with their spreadsheets... no email required. Managed files also help with resource usage especially for such events as month end or daily reports using things like Crystal Reports or SSRS. It's far better to have one file somewhere that people can get to than to have hundreds of people all trying to run the same report. It kind of reminds me of the old "green bar" days where people would have a 40 pound bundle of green-bar paper reports delivered to their desk... they'd flip to page "x" and "y" to get a couple of numbers and then throw away the report. It was really silly and wasteful especially considering the number of people that it actually took to build the reports and deliver them.

--Jeff Moden

RBAR is pronounced ree-bar and is a Modenism for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
Although they tell us that they want it real bad, our primary goal is to ensure that we dont actually give it to them that way.
Although change is inevitable, change for the better is not.
Just because you can do something in PowerShell, doesnt mean you should. Wink

Helpful Links:
How to post code problems
How to post performance problems
Forum FAQs
Jeff Moden
Jeff Moden
SSC-Forever
SSC-Forever (45K reputation)SSC-Forever (45K reputation)SSC-Forever (45K reputation)SSC-Forever (45K reputation)SSC-Forever (45K reputation)SSC-Forever (45K reputation)SSC-Forever (45K reputation)SSC-Forever (45K reputation)

Group: General Forum Members
Points: 45277 Visits: 39934
Dave Vroman (6/20/2013)
[p]Because of PCI compliance, both xp_cmdshell and db_sendmail are disabled on our database servers. I needed to get some of my tasks to send email to me so I used CDOSYS.


Since anyone with "SA" privs (attacker or overcurious DBA) can easily get to the command prompt either by turning xp_CmdShell on or through other methods, I'm curious why the PCI would require such a thing. It's been years since I've read/studied the PCI spec. Do you happen to have a link for it?

--Jeff Moden

RBAR is pronounced ree-bar and is a Modenism for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
Although they tell us that they want it real bad, our primary goal is to ensure that we dont actually give it to them that way.
Although change is inevitable, change for the better is not.
Just because you can do something in PowerShell, doesnt mean you should. Wink

Helpful Links:
How to post code problems
How to post performance problems
Forum FAQs
Dave Vroman
Dave Vroman
SSC-Enthusiastic
SSC-Enthusiastic (163 reputation)SSC-Enthusiastic (163 reputation)SSC-Enthusiastic (163 reputation)SSC-Enthusiastic (163 reputation)SSC-Enthusiastic (163 reputation)SSC-Enthusiastic (163 reputation)SSC-Enthusiastic (163 reputation)SSC-Enthusiastic (163 reputation)

Group: General Forum Members
Points: 163 Visits: 716
I didn't do that portion of the requirement. I only got the results. I wrote their encryption package and their encryption interface fully compatible with classic ASP, VB.NET, ASP.NET and VB6 and SQL. I was in charge of the DTS / SSIS packages and needed results from them and ran into several roadblocks. The compliance requirements were especially stringent because the web site got hacked with all of the resulting hassles.
bdavey
bdavey
Valued Member
Valued Member (54 reputation)Valued Member (54 reputation)Valued Member (54 reputation)Valued Member (54 reputation)Valued Member (54 reputation)Valued Member (54 reputation)Valued Member (54 reputation)Valued Member (54 reputation)

Group: General Forum Members
Points: 54 Visits: 286
Steve,
Great article. Thanks for sharing.
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search