Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion Groups
DB Engine
SQL ServerMSDESQL Server CE
Services
Analysis (Data Mining)Analysis (OLAP)DTSIntegration ServicesNotification ServicesReporting Services
Programming
CLRConnectivitySQLXML
Other Technologies
ClusteringEnglish QueryFull-Text SearchReplicationService Broker
General
Data WarehousingPerformanceSecuritySetupSQL Server ToolsOther SQL Server Topics
DirectoryUser Groups
Related Topics
MS AccessOther DB ProductsMS Server Products.NET DevelopmentVB DevelopmentJava DevelopmentMore Topics ...

SQL Server Forum / Services / Reporting Services / July 2008

Tip: Looking for answers? Try searching our database.

Web Archive not rendering to email properly

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Jason - 25 Jul 2008 20:19 GMT
Hello all,

I am struggling with the rendering of Web Archive (MHTML) into email.
In the report, the tables are sized correctly for display, but when
rendered as MHTML and placed into an Outlook message, the table widths
are tiny. It seems as though they default to about 4 inches, when in
the report they are actually around 8 inches.

When I look at the source of the MHTML, the individual cells (<td>
elements) are sized correctly. The sizes have been converted into mm
(8.125" to 206.38mm), but the containing table has no width property.

When viewed in a browser this doesn't present a problem. The
individual cell widths take priority and format the table. When copied
into an Outlook message, since the actual table elements don't have a
set width they shrink, and as a result the individual cells shrink
too.

I can manually edit the html source and assign the table elements the
right width, and it copies into Outlook fine. Just the way I want it.

Anyone come up with a way to get around this? Is there an additional
property in the RDL file I can set, or in Visual Studio to force the
width property into the table elements?

Thanks,
Jason
Jason - 29 Jul 2008 18:33 GMT
> Hello all,
>
[quoted text clipped - 23 lines]
> Thanks,
> Jason

Nevermind, I found a low tech solution. I added a textbox to the top
of the report containing an unbroken line of underscore characters.
After setting the right width (took some trial and error), I just set
the font to the same color as the background to be invisible.
With the continuous set of characters the report as a whole didn't
word wrap and shrink all the table elements as before.

I saw a couple of similar older posts about the same problem. Take the
solution for what it's worth.

- Jason
tideland - 30 Jul 2008 23:44 GMT
I'm experiencing this same problem and have identified this as a bug.

The problem exists within the source code of the Web Archive report which is
dynamically generated and transmitted via email.

Each Web Archive email contains an embedded style sheet where each class is
declared successively (.a1, .a2, .a3, .a4, etc.).

If you View Source from your email and examine the classes very carefully,
you'll notice that Reporting Services has dropped the "period" which should
precede each declared class.

Example: .a1, .a2, a3, a4, etc.). In this case, any of the objects which
reference classes a1 and a2 are fine but, any objects referencing a3 and a4
will have no formatting whatsoever because they're effectively misspelled.

That's the problem, it looks programmatic since the styles are direct
translations of the ones which are set in the Object Properties of the Report
Designer.

Most likely, there are a set of conditional or 'case' statements in the
source code of Reporting Services email generation library where the
Developer accidentally ommitted the necessary period, so when case = x the
periods are there, but when case = y they're missing and the class name is
wrong.

This needs to have a Bug Tracker assigned to it.

> Hello all,
>
[quoted text clipped - 23 lines]
> Thanks,
> Jason
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.