Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase ««12345»»»

Email Formatted HTML Table with T-SQL Expand / Collapse
Author
Message
Posted Thursday, June 20, 2013 7:56 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Friday, April 11, 2014 12:33 PM
Points: 1, Visits: 6
Does this work when those e-mails are opened using outlook 2007 or later versions?
Post #1465715
Posted Thursday, June 20, 2013 8:15 AM


SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: Wednesday, April 16, 2014 8:22 AM
Points: 453, Visits: 102
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.
Post #1465726
Posted Thursday, June 20, 2013 8:17 AM


SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: Wednesday, April 16, 2014 8:22 AM
Points: 453, Visits: 102
I've never had a problem with any of the email clients. Simple HTML is recognized by all of them.
Post #1465728
Posted Thursday, June 20, 2013 9:15 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Thursday, June 26, 2014 7:28 AM
Points: 257, Visits: 902
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" :)

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. :)
Post #1465762
Posted Thursday, June 20, 2013 9:24 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Today @ 12:14 AM
Points: 36,735, Visits: 31,186
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."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1465773
Posted Thursday, June 20, 2013 9:28 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Monday, July 21, 2014 12:47 PM
Points: 150, Visits: 591

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'

Post #1465781
Posted Thursday, June 20, 2013 10:04 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Today @ 12:14 AM
Points: 36,735, Visits: 31,186
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" :)

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. :)


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."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1465808
Posted Thursday, June 20, 2013 10:11 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Today @ 12:14 AM
Points: 36,735, Visits: 31,186
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."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1465815
Posted Thursday, June 20, 2013 10:20 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Monday, July 21, 2014 12:47 PM
Points: 150, Visits: 591
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.
Post #1465824
Posted Thursday, June 20, 2013 11:29 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Thursday, July 17, 2014 8:51 AM
Points: 48, Visits: 280
Steve,
Great article. Thanks for sharing.
Post #1465864
« Prev Topic | Next Topic »

Add to briefcase ««12345»»»

Permissions Expand / Collapse