Explore Posterous

sqlshots: Reporting Services 2005 - Unable to load client print control

I received a trouble support call from a client that encountered an error while attempting to print a Report via Reporting Services. The client was able to print before then suddenly it became an issue. Coincidentally Microsoft released two hotfixes (KB956803 & KB956391) which added a “kill-bit” associated to the ActiveX printing control used by Reporting Services 2005.

Hotfix KB956803 only affects Windows XP & Windows 2003 platforms while Windows 2000, Vista and 2008 platforms were not affected.  Hotfix KB956391 seems intended to patch vulnerabilities within the Office products.

There are a few ways to go about it and correct it:

Possible Solutions on the (Client Side)

1)      Uninstall both hotfixes (KB956803 & KB956391)

2)      Install the following Reporting Services update (http://www.microsoft.com/downloads/details.aspx?FamilyID=82833f27-081d-4b72-83ef-2836360a904d&DisplayLang=en)

3)      Delete a single key in the registry (Which is what I chose)

Corrective Steps for item 3

a)      I located and deleted the following key from the registry. [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{FA91DF8D-53AB-455D-AB20-F2F023E498D3}]

b)      Then I had restarted (close/re-launched) all IE sessions

c)       Browsed to the Reporting Services url

d)      Opened a report

e)      Clicked the print button (if you have or haven’t installed the print client you may or may not receive the yellow “Install ActiveX” dialog just below the IE header area. You may just receive the Print Dialog instead.)

f)       The report printed fine

Loading mentions Retweet

Comment (0) »

sqlshots: Delivering subscriptions outside the Organization

Recently I faced an issue with reporting services 2005 when attempting to deliver subscriptions to addresses outside of the organization. Internal addresses received the email based subscription deliveries without any questions. I must have checked and re-checked the settings using RSConfigTool about million times, looking for anything I might have overlooked. The error message I received was, "The e-mail address of one or more recipients is not valid". After some research (which lead me to a lot of dead ended forums) I read the phrase "email relay", that's when the gears started spinning.

I realized that the issue had nothing to do with the configuration of SQL Server Reporting Services; rather, the SMTP server! In order for the messages to be delivered outside of the organization the Reporting Services Server needed to be authorized so-to-speak. Unfortunately I don't have access to Exchange 2003 so I cannot provide screen shots, but for 2007 all you need to do is add the server's IP Address to the SMTP server’s receiver group in the HUB Transport configs.

Then to test your subscription without tweaking the schedule execution time just run the SQL job! First find out the name of the job by using the attached sql script, then execute the sp_start_job. If you have a named instance append $instancename to all three of ReportServer occurrences within the sql script (i.e. ReportServer$InstanceName) for MSSQL 2005. I believe for MSSQL 2008 you would append _InstanceName (i.e. ReportServer_InstanceName), but I am not certain. You should get the results similar to the screen shot attached.

   

Click here to download:

sqlshots_Delivering_subscripti.zip (54 KB)

Using the script with a default instance

 SELECT	
    sj.[name] AS [Job Name], 
    c.[Name] AS [Report Name], 
    c.[Path], 
    su.Description, 
    su.EventType, 
    su.LastStatus, 
    su.LastRunTime 
 FROM msdb..sysjobs AS sj INNER JOIN ReportServer..ReportSchedule AS rs 
    ON sj.[name] = CAST(rs.ScheduleID AS NVARCHAR(128)) INNER JOIN 
    ReportServer..Subscriptions AS su 
    ON rs.SubscriptionID = su.SubscriptionID INNER JOIN 
    ReportServer..[Catalog] c 
    ON su.Report_OID = c.ItemID 

Using the script with a named instance

 SELECT	
    sj.[name] AS [Job Name], 
    c.[Name] AS [Report Name], 
    c.[Path], 
    su.Description, 
    su.EventType, 
    su.LastStatus, 
    su.LastRunTime 
 FROM msdb..sysjobs AS sj INNER JOIN ReportServer$InstanceName..ReportSchedule AS rs 
    ON sj.[name] = CAST(rs.ScheduleID AS NVARCHAR(128)) INNER JOIN 
    ReportServer$InstanceName..Subscriptions AS su 
    ON rs.SubscriptionID = su.SubscriptionID INNER JOIN 
    ReportServer$InstanceName..[Catalog] c 
    ON su.Report_OID = c.ItemID 

Execute the report

 USE msdb EXEC sp_start_job @job_name = 'AF015D8B-D80D-4D2A-9808-CD1D519B3332' 

Correction
In the attached file listed below I have identified a typo. Currently it states on
Line 19: sp_start_sp (which is incorrect) it should be
Line 19: sp_start_job

Click here to download:

SELECT.Get_RSSubscription_Jobs_v0.02.sql (0 KB)

Loading mentions Retweet

Comment (0) »

Column headings do not repeat in SSRS 2008

I've just stumbled upon an odd issue with the Tablix control in SSRS 2008.  I deployed a report on a server a few weeks ago and it is now reporting on enough data to make it span multiple pages.  I wanted the column headings to appear on all pages, not just the first.  However, when I set the RepeatColumnHeaders property on the Tablix to be true, the headings still did not appear on the next page.  After a bit of playing around I enabled Advanced Mode in the Grouping Pane, and had a look at the properties for the top (Static) group in Row Groups.  Under Other, there is a property called RepeatOnNewPage.  Setting this to True made the column headers appear as required.  OK, so that's fine, but I can't help but think that this a a bug in SSRS 2008, and should be fixed by MS.  Looking through the RDL file itself, I can't find anything that would cause the RepeatColumnHeaders property not to behave as expected.

The "Header should remain visible while scrolling" option does not appear to work either; I haven't yet found a workaround for this.

Loading mentions Retweet

Comment (5) »

Formatting Dates in SSRS

In Reporting Services, formatting dates can become a headache for the developer, often due to differing regional settings on servers, development boxes etc.  Therefore I've found it much more useful to force the report to use a particular format, rather than allow the server settings to decide for me.  Previously I would have used FormatDateTime in the expression, as shown here:

=FormatDateTime(Fields!DateStamp.Value, DateFormat.ShortDate)

Depending on the regional settings, this could return either 12/3/2008 or 3/12/2008.  When designing the report, I want to know exactly what the date will look like, no matter where it is deployed.  So I instead use the Format function to allow me to choose the format I require.  Some examples:

=Format(Fields!DateStamp.Value, "dd-MMM-yy")
returns 03-Dec-08

=Format(Fields!DateStamp.Value, "dd-MMM-yyyy")
returns 03-Dec-2008

=Format(Fields!DateStamp.Value, "dd-MMMM-yy")
returns 03-December-08

=Format(Fields!DateStamp.Value, "dd-MMM-yyyy H:mm")
03-Dec-2008 16:44

This method removes a lot of the issues regarding date formatting, and means there are no shocks or questions when it comes to deployment time!

Edit: Setting the Language property of the report to your locale will also ensure that dates in your report parameters will have the correct format.  This is something that is often overlooked.

Loading mentions Retweet

Comment (0) »