Consider the following scenario:
- You create a Windows Forms application or a Windows Presentation Foundation (WPF) application that is based on the Microsoft .NET Framework 4.0.
- In the Windows Forms or WPF application, you use a Microsoft Report Viewer 2010 control to display a Microsoft SQL Server 2012 Reporting Services (SSRS 2012) report that runs in remote mode.
- The report includes a DateTime type parameter that has a default value.
- You run the application on an operating system that has the regional settings set to Italian. Additionally, the Long Time format is set to "HH:mm:ss".
In this scenario, you may experience one of the following issues:
- The default value of the DateTime type parameter is not displayed in the parameter prompt area.
- If you assign a value to the DateTime type parameter and update the report, the value is lost after the report is rendered and is not displayed.
This issue occurs because of a change in the .NET Framework 4.0 that prevents the application and SSRS 2012 from using the correct information based on the regional settings of the operating system. Applications that are based on the .NET Framework 4.0 use regional settings that are returned by Windows. However, SSRS 2012 is built on the .NET Framework 3.5 Services Pack 1 (SP1). Therefore, SSRS 2012 uses the regional settings that are embedded in the .NET Framework 3.5 SP1.
When a SSRS 2012 server runs a report by using the "." symbol as a time separator, the DateTime
type parameter is sent back to the client as a string. The Report Viewer control calls the DateTimeOffset.TryParse
method to validate the string by using the ":" symbol as the time separator. Therefore, the string is validated as false and it is not displayed in the parameter prompt area.Note
This issue only occurs if the Long Time
format is set to "HH:mm:ss", the default setting for Italian regional settings. The default setting for Italian regional settings depends on your operating system. Additionally, you can configure the default setting of your operating system by changing the Long Time
Cumulative update information
Cumulative update 2 for SQL Server 2012 Service Pack 1 (SP1)
The fix for this issue was first released in Cumulative Update 2. For more information about how to obtain this cumulative update package for SQL Server 2012 Service Pack 1, click the following article number to view the article in the Microsoft Knowledge Base:
Cumulative update package 2 for SQL Server 2012 Service Pack 1
Because the builds are cumulative, each new fix release contains all the hotfixes and all the security fixes that were included with the previous SQL Server 2012 Service Pack 1 fix release. We recommend that you consider applying the most recent fix release that contains this hotfix. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
The SQL Server 2012 builds that were released after SQL Server 2012 Service Pack 1 was released
Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section.
To work around the issue, use one of the following workarounds:
- Set the regional settings on the application and the operating system to match the regional settings that are located on the client.
- Create a string input field for the user to populate with text. Then in the report, convert the string to a date.
- Create a hidden or no-prompt parameter that is populated from the string input field when you run the report.
- Create a non-visible DateTime type parameter and a DateTimePicker control outside the Report Viewer control. Click View Report, and then put the string value into the DateTime type parameter in the SubmittingParameterValues event handler.
Microsoft Report Viewer 2010 SP1 Redistributable Package is available to download from the following Microsoft Download Center website:
To know more about DateTimeOffset.TryParseExact
method and DateTimeOffset.TryParse
Method, visit the following MSDN websites: