SQL Server Reporting Services (Sharepoint Integration) Culture/Region Issue - by Phillip Zada

Status : 

  Not Reproducible<br /><br />
		The product team could not reproduce this item with the description and steps provided.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 777829 Comments
Status Closed Workarounds
Type Bug Repros 4
Opened 1/29/2013 7:08:22 PM
Access Restriction Public


SSRS SharePoint integration mode fails to account for Australian formatting. This results in US format dates and issues when utilising date time picker in the report parameters. The report is sent to the correct region and I've applied SQL 2012 SP1 CU2 with no luck.

I've got a manually work around for the parameters which involves editing the "C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\TEMPLATE\LAYOUTS\ReportServer\RSViewerPage.aspx" file and applying the following update <%@ Page language="C#" Codebehind="RSViewerPage.aspx.cs" AutoEventWireup="false" Inherits="Microsoft.ReportingServices.SharePoint.UI.RSViewerPage,Microsoft.ReportingServices.SharePoint.UI.ServerPages,Version=,Culture=neutral,PublicKeyToken=89845dcd8080cc91"  Culture="en-AU" UICulture="en-AU" %>

But other areas such as subscription scheduler cannot be patched.
Sign in to post a comment.
Posted by Chris OConnor on 9/22/2014 at 4:30 PM
This workaround is fine for the "ReportViewer" display - but the same issue occurs for the "ReportViewerWebPart" when added to a page.    Is there any way to FIX this ?     Which CU will work / not break it ?
Posted by Stig on 7/7/2014 at 3:34 AM
Thanks for posting, but for anyone that has to support multiple locales the workaround of setting this to one specific locale is not really helping. We have users in all European countries and frankly they are laughing at Microsoft for still not being able to fully and smartly support international dates in 2014. Same kind of issues that we used to have in the 90s.
Posted by Mike Honey - Manga Solutions on 5/5/2014 at 6:59 PM
I've struck this same issue. I followed a blog post to workaround it - I'll post the details under Workarounds.

CUs and Hotfixes arent an option at this site. SharePoint is 2013 RTM. SSRS is 2012 SP1.
Posted by Matt [MSFT] on 12/20/2013 at 1:37 PM
Thanks again for your feedback. That is good to know about the upgrade experience. Even better, I'm glad everything is working for you now :).

Matt Jones
SSRS Tiger Dev
Posted by CloudCatalyst on 11/25/2013 at 2:49 PM

Thanks for your pointers. In an attempt to simplify the problem we tested the upgrade on an all-in-one instance and the date issue went away. This gave us hope that it has been resolved but the technique we used to install the update was the problem.

As part of the original build we followed the published guide which recommends the use of rsSharePoint,.msi (http://www.microsoft.com/en-us/download/details.aspx?id=35583) to install the add-ins feature code to the WEFs. When we tried running the CU installer on these boxes it didn't indicate that the Reporting Services SharePoint Add-ins needed to be updated. We assumed that this meant that the update didn't need to make any changes to the add-in, which seemed strange considering the nature of the issue that we were trying to resolve.

Once we determined that the CU did actually fix the problem we guessed that at some point the add-ins did get upgraded and that each WFE needs an update. Once we ran the CU installer on each WFE and ignored the fact that it didn't mention that the add-ins would be upgraded (until the success message after the install was completed) the problem went away.

In hindsight we should have given this a shot earlier but as there was no indication from the installer that it would actually upgrade the add-in we didn't bother continuing what we assumed was an unnecessary the install on a production environment.

Thanks again for your help and thanks to the team for resolving this issue.
Posted by Matt [MSFT] on 11/14/2013 at 6:19 PM
Hello CloudCatalyst,

Can you please verify the versions of SharePoint, Reporting Services Add-in, and Reporting Services? The scenario described in the hotfix has been fixed and tested, and it sounds just like your scenario. I know it can be tricky updating both the Reporting Services Add-in and the Reporting Services instance(s).

Here are some helpful articles:


Please review these to double check if the cumulative update resolves your issue.

Matt Jones
SSRS Tiger Dev
Posted by CloudCatalyst on 11/7/2013 at 7:20 PM
I'm also able to reproduce this issue on a similar environment. We've applied CU 6 (http://support.microsoft.com/kb/2874879) to all instances of SQL 2012 SP1 as it appeared to have been resolved by hotfix http://support.microsoft.com/kb/2764343 which we assume is included in CU 6.

Unfortunately the issue still exists. The SharePoint site is configured with the Regional Settings locale of en-AU and the calendar picker appears to be returning the date to the form in an Australian format but the DateTime parameters on the page re-render in US format.

If the AU date (e.g. 29/11/2013) is an invalid US date the full data and time is displayed in US format (11/29/2013 12:00:00 AM) and the calendar is no longer able to determine the selected date when it selected.

We are able to force the culture of the page using Phillip's suggested change to the aspx page but as this is a hard-coded change to a file in the 15 hive we are not comfortable making this change in a supported production environment.
Posted by Matt [MSFT] on 10/16/2013 at 10:45 AM
Thanks for your feedback. I am looking into this issue.

Matt Jones
SSRS Tiger Dev
Posted by Andy Emmett on 8/1/2013 at 5:20 AM
I have had the same problem with en-GB. SharePoint 2013 with SQL 2012 SP1. Have done exactly as described above and it worked, however it seems to have introduced some visual display issue. They are not show stoppers, but am not sure it what MS intend the page to look like. BTW, why is RS still targeting IE 7! meta tags forcing ie 7 <meta http-equiv="X-UA-Compatible" content="IE=7" /> are being generated which causes visual differences between different browsers... Surely is time to dump IE7....