Hi, I am using SSRS 2008R2 in an embedded scenario where SQL Server Express is providing data services to my application. I have several *local* reports (not stored in an SQL Server instance), that are working well and which have had their text localized into a number of languages. These reports are delivered in WinForms forms in the application via the Microsoft.Reporting.WinForms.ReportViewer .NET control. My remaining problem is localization of some of the built-in operations in reporting, like display of dates and times. Regardless of which locale is set in my test systems (Windows XP), French (France) say, my dates are shown mm/dd/YYYY and times as HH:MM:SS AM/PM. Both of these are just plain dead wrong for 50%+ of the world, but I can't find any way to get the reporting services to use the correct formats. The typical use of these values is in a title block that shows the date and time range for a given report. My questions are: * Is there any debugging capability, logging capability, etc. that I can use to help understand why SSRS is behaving badly? * Is there a setting, configuration, or method call into reporting services (via the ReportViewer control, maybe), that will force date/time display to be performed according to Microsoft guidelines? * If the answers to the above are basically "no", what would you do? Localization is non-negotiable; date/time format has to be localized; having separate reports for different locales is not appropriate in this application. Thanks, Paul T.

Hi Paul, To your first question "Is there any debugging capability, logging capability, etc. that I can use to help understand why SSRS is behaving badly?" Reporting Services' life circle contain several aspects (Creating, Randering, Managing, and Delivering Reports), it does not make sense to use one specific debug tool to debug all aspect issue, if your issue come from Custom Code/Accembly/Extension, you can debug it using Visual Studio just like debuging project. if you have performance issue, you should have a check to the values in there three columns TimeDataRetrieval, TimeProcessing, and TimeRendering from ExecutionLog2 table in the ReportServer database when the report is executed. In this way, we could get to know the performance of each step. And give relevant optimization based on: My data takes too long to retrieve ; My report takes too long to process ; My report takes too long to render; if you have permission and credential issue, you should see How to set Store Credentials for a Data Source, and setting Permissions in Reporting Services, Besides this there are also some issue from reporting services integrated into sharepoint, retrieve datasource from cub, RDLC report, export, print, although we have no perticular debug tool but we have solution to debug every aspect issues. In addition, we have many log file which trace the issue such as: Report Server Execution Log ;Report Server Service Trace Log ; Report Server HTTP Log; Windows Application Log ;Windows Performance logs; Setup log files; all of these logs can help you troubleshoot the issue. To your second question "Is there a setting, configuration, or method call into reporting services (via the ReportViewer control, maybe)" We can make use of ReportViewer control to achieve this requirement, actually Reportviewer control has two process modes: Local mode and remote mode, we can programmatically configure the processing mode for a ReportViewer control, the processing mode is set for remote processing using a published report that runs on a SQL Server Reporting Services report server, If dynamic configuration is not an application requirement, you can set the processing mode at design time using the ReportViewer Tasks smart tag panel. For more information, see Using the ReportViewer Tasks Smart Tags Panel and Adding and Configuring the ReportViewer Controls. Your last question concern report's Localization. Actually, both the client application (usually a browser) and the operating system of the computer that is running the report server play a part in determining which language resource is used. To the data format of the calendar control on report manager or reprot server, it is relevant to your browser and operating system's language. To report's content, you need to store your “description text” in multiple languages in a table and use a parameterized query to gain the correct record based on User!Language. If you are using the cub as datasource, the SQL Analysis Services Translations feature makes all this a thing of the past, you can use this great feature to localize all your text, including captions, data, etc. For more information about Multi-Lingual or Global Deployments (Reporting Services), please see: http://msdn.microsoft.com/en-us/library/ms156493.aspx If you have any other language, please feel free to ask. Thanks, Challen Fu Forum Support If you have feedback for TechNet Subscriber Support, please contact us Please remember to mark the replies as answers if they help and unmark them if they provide no help.

Your last question concern report's Localization. Actually, both the client application (usually a browser) and the operating system of the computer that is running the report server play a part in determining which language resource is used. To the data format of the calendar control on report manager or reprot server, it is relevant to your browser and operating system's language. To report's content, you need to store your “description text” in multiple languages in a table and use a parameterized query to gain the correct record based on User!Language. If you are using the cub as datasource, the SQL Analysis Services Translations feature makes all this a thing of the past, you can use this great feature to localize all your text, including captions, data, etc. All of my reports are locally processed (as mentioned in my initial description, this is an application where the SQL Server Express database is embedded with the application program). The user, I hope, knows NOTHING about SQL Server; it's not even a feature of the application, it's just a tool for data storage. The client application, as indicated IS NOT A BROWSER. It's a WinForms application, .NET 4.0. The only locale settings in question should be those on the single machine where the application runs, where the data is resident and where SQL Server Express is installed. Those settings are correct for the various locales that I'm testing, French (France), say. However, despite the fact that the locale settings for French (France) specify the date/time format correctly for that country/locale, the report is NOT CORRECTLY RENDERED WHEN DATE/TIME VALUES ARE DISPLAYED. This is out of my direct control and appears to me to be a bug in the local processing of reports. My own text is already localized and is working perfectly (it's my code and I can control it and have done so). Your code, however, which I don't seem to be able to control, as far as how date/time values are displayed, is not working correctly. It's possible that there is some property or method that I need to call to notify the ReportViewer control or the reporting service within SQL Express embedded in my application that I want the correct locale settings to be used. I don't see such a setting, however. That's what I'm asking: what do I have to do to make the report render correctly based on the locale selected for the operating system or for my application? Paul T.

Here's an image showing a report that demonstrates the date/time formatting error: http://tinyurl.com/4xqrf5c This report is a chart of some data. Everything that says "(French)" inside it is properly localized (by me), to the French (France) locale set for the current operating system. You'll note that I don't write in French, so you can read generally what's supposed to be there in English. The dates in the report header are shown in the default date/time localization format for the operating system on the machine. The error is clearly seen in the X axis of the chart where the dates and times appear to be formatted in some format matching the English (USA) OS (or something). That's what needs to be fixed, so you need to point me to information on how SQL Server Express is deciding to format dates/times in that way and how to tell it to perform differently. Paul T.

Hi Paul, Thanks for your detail information, based on the chart you gave, it seems you don't want to display the date label on the X-Axis in that format, you want to show the format as the label on the header on top of the chart, right? If I misunderstand you, please feel free to let us know. If that is what you want, I think you should reset Report Language to fr-FR just like the link in my first reply, steps are: 1. Switch your report to Design mode. 2. In the properties' drop-down list, please select Report. 3. Locate its Language property, then select fr-FR in the drop-down list. Then you will get the date on the X-Axis like this format 22/6/2011 rather than 6/22/2011 Thanks, Challen Fu Please remember to mark the replies as answers if they help and unmark them if they provide no help.

I want to display the date/time format IN THE CORRECT FORMAT CHOSEN BY THE USER FOR HIS MACHINE. Please note my original statement, "... localized into a number of languages". Setting the design-time language to French (while it works, for French, is broken, then for English (USA)), doesn't address my problem. I DON'T KNOW WHAT LANGUAGE THE USER WILL BE USING AT RUN-TIME WHEN I BUILD THE REPORT. At run-time I don't see any way to tell the report, which may be stored on disk as a .RDLC file, or worse, in an embedded resource as part of the application code itself, that it should now render in English, French, Italian, Chinese, Swedish, or whatever. Since the language does and unavoidably will be different on different installations of the application, in one way or the other the language to use has to be determined at run-time. My example is simply to show that the report rendering engine is broken, or at least that it does not follow Microsoft's own standards for using the application locale to decide how to format dates and times. If you have a means to tell it, at run-time, to use a specific locale for rendering, I'm happy to use that, but I don't see one. Think of it this way, I'm Amazon.com. I have a report that I want to show to users which lists their purchases. However, the user might be a Spanish-speaking user in the USA, a Chinese-speaking user in Taiwan, a Russian-speaking user in Romania, etc. I can't build a different report for all of those situations; that would be unmaintainable. I have the same problem in my case except that the server and the application viewing the report are on the same machine, not located across the Internet. If the report service would simply look at the locale on the machine or have some means for the ReportViewer control to pass it locale information, everything would be fine. I presume you must do something like this to render reports in a browser, no? Paul T.

Hi Paul In you post, I notice you mentioned .RDLC, local report, you still mentioned Reporting Services, Could you please more specific what's the kind of your report? Thanks for your confirmation. Regards, Challen Fu Please remember to mark the replies as answers if they help and unmark them if they provide no help.

It's a local report (I think I've said that). The documentation does not provide a way to describe the reporting services, when local, other than Reporting Services. The report is generated on the local PC USING SQL SERVER EXPRESS. If you have some other method of describing that, I'd be happy to know what it is (and even happier if you'd tell the documentation team!). Paul T.

My example is simply to show that the report rendering engine is broken, or at least that it does not follow Microsoft's own standards for using the application locale to decide how to format dates and times. If you have a means to tell it, at run-time, to use a specific locale for rendering, I'm happy to use that, but I don't see one. Think of it this way, I'm Amazon.com. I have a report that I want to show to users which lists their purchases. However, the user might be a Spanish-speaking user in the USA, a Chinese-speaking user in Taiwan, a Russian-speaking user in Romania, etc. I can't build a different report for all of those situations; that would be unmaintainable. I have the same problem in my case except that the server and the application viewing the report are on the same machine, not located across the Internet. If the report service would simply look at the locale on the machine or have some means for the ReportViewer control to pass it locale information, everything would be fine. I presume you must do something like this to render reports in a browser, no? Hi Paul, To decide which language to use at run-time, you need to create a parameter(language) for your user to select, based on the parameter's value choose, we can decide which language to use at run-time, Just like you mention the "user might be a Spanish-speaking user in the USA", to this scenario, you just need to select Spanish in the parameter's drop-down list with value es-ES, then all the date type value will be displayed in Spanish date format. To set report's language using the parameter, you should first create a single-value parameter whose available value are all kinds of language value you need, then follow my second reply's step, type in the expression for report's language property =Parameters!YourParameterName.value. Of course, you can also using below expression in your report body directly =CDate(Fileds!Date.value).ToString(System.Globalization.CultureInfo.CreateSpecificCulture(Parameters!YourParameterName.value)) Note: here Date is your data field name, Parameters!YourParameterName.value is your parameter’s name. For more information about how to pass parameter’s value in local report, please see this FAQ in our team’s blog: http://blogs.msdn.com/b/sqlforum/archive/2010/12/21/faq-how-do-i-work-parameters-with-a-local-report.aspx Thanks, Challen Fu Please remember to mark the replies as answers if they help and unmark them if they provide no help.

I'm pretty experienced with parameters, passing about 50 to each of these reports (about half of them for localization)... I've tried your suggestion with the following code for the Category item Label property of my chart: =CDate(Fields!SampleDateTime.Value).ToString(System.Globalization.CultureInfo.CreateSpecificCulture(User!Language)) You'll note that I don't have to pass the language as an extra parameter of the report, since I just want to use the current user language. I use the built-in field User!Language. I've verified that this matches the locale that the rest of my application is running (in my test case, "fr-FR"). However, the category axis (x-axis), labels on the chart are still displayed using the US-English format (mm/dd/yyyy hh:mm:ss AM/PM), not the French(France) format (dd/mm/yyyy hh:mm:ss). did you try your own suggestion to make sure it works? Paul T.

Please forgive my narrative; I hope that it will help someone else. Based on trying to make your solution work, I found that it was probably hopeless (I don't want a category axis; it's a date/time, so it needs to be treated as a scalar), so I decided to make another try at the Category Axis Properties' Number formatting. This is where there's clearly (to me, at least), something wrong with your design choices. I have a DateTime type as my (scalar) axis value. If I select Date in the Category list and select a suitable format (7/15/2011 10:33:40 AM, that is short-date/long-time), I'd expect this to be localized (in fact it says that it will be localized in the help). Unfortunately, it's localized based on the fixed and unchangable locale assigned to the report (so you might as well just not worry about localizing it!) One alternative that I looked at some time ago was the custom format. DateTime.ToString() has a formatting character for exactly the format that I want, "g". I've previously tried to use that as the custom format for my axis and found that, stubbornly, you guys have decided to actually do the format based on the locale of the report, not the locale of the user's system. My thought, though, was that maybe I could get the actual format, not the "g" shortcut by the "MM/dd/yyyy HH:mm:ss" format and use that as my custom format string, effectively bypassing your "localization" operation. It's a mess, but the following function code assigned to the Custom Format property gives the right answer at run-time for whatever locale the application is using: =System.Globalization.CultureInfo.CreateSpecificCulture(User!Language).DateTimeFormat.ShortDatePattern+ " "+ System.Globalization.CultureInfo.CreateSpecificCulture(User!Language).DateTimeFormat.LongTimePattern Obviously, code this ugly would get me fired if I wrote it myself, but there does not appear to be a way to, for example, call CreateSpecificCulture() once and then query the culture for ShortDatePattern and LongDatePattern. I tried report variables and, a value of: =System.Globalization.CultureInfo.CreateSpecificCulture(User!Language).DateTimeFormat can't be evaluated (the report generates an error. So, at least my dates and times are formatted correctly, even though the performance is probably horrible... Thanks for working on the issue. Please pass along that I think a serious mistake has been made in locking a report to a language! Paul T.