Home Dashboard Directory Help
Search

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


Status: 

Active


3
0
Sign in
to vote
Type: Bug
ID: 777829
Opened: 1/29/2013 7:08:22 PM
Access Restriction: Public
0
Workaround(s)
view
2
User(s) can reproduce this bug

Description

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=11.0.0.0,Culture=neutral,PublicKeyToken=89845dcd8080cc91" Culture="en-AU" UICulture="en-AU" %>

But other areas such as subscription scheduler cannot be patched.
Details
Sign in to post a comment.
Posted by Microsoft 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 :).

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

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 Microsoft 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:

http://technet.microsoft.com/en-us/library/aa905871.aspx
http://msdn.microsoft.com/en-us/library/gg426282(v=sql.120).aspx

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

Thanks,
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 Microsoft on 10/16/2013 at 10:45 AM
Thanks for your feedback. I am looking into this issue.

Thanks,
Matt Jones
SSRS Tiger Dev
Posted by aemmett 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....
Sign in to post a workaround.