We use cookies to give you the best experience on our website. If you continue to browse, then you agree to our privacy policy and cookie policy.
Unfortunately, activation email could not send to your email. Please try again.

Problems with DateTime Report Parameter

Thread ID:

Created:

Updated:

Platform:

Replies:

132567 Sep 8,2017 11:37 AM Sep 13,2017 04:35 AM Report Platform 4
loading
Tags: Report Viewer
Nellinger
Asked On September 8, 2017 11:37 AM

Hi Support Team,

I have a couple of problems (maybe misunderstandings) with a DateTime report parameter:

1) How do I set up the formatting of the DateTime? Does it depend on the system regional settings? If so, it is not doing so for all parts! On the Report Server I am currently using German Location and Formats which means "dd.mm.yyyy". Somehow the value which has to be entered via report parameter only accepts mm/dd/yyyy BUT the report itself displays the passed parameter value in the German format although I do not apply any kind of format string - see image below:

If I try to enter sth. like 15/9/2017 it does not work because there is no month 15 and so I cannot enter all needed values.

2) The DateTime format of the ReportDesigner and the web site (after saving the RDL file on the server) is not the same. What are the system settings which have an influence on this formatting?

3) The parameter says "DateTime" but I am only able to enter a date without the time part. Where can I adjust this?

4) I have set default values for the two DateTime parameters but I still have have to enter values manually. For example I have used the value =Today() for the start parameter, but it simply does not work. When entering a default value in SSRS this value will be used for the initial data request but it seems the your ReportServer acts differently. What could be the reason for this?

I appreciate your help!


Nellinger
Replied On September 12, 2017 06:21 AM

Any help to at least one of the listed questions/problems is appreciated!


Yuvaraj Devarajan [Syncfusion]
Replied On September 12, 2017 07:30 AM

Hi Björn, 
 
Thanks for contacting Syncfusion support. 
 
Any help to at least one of the listed questions/problems is appreciated! 
Sorry for the delay. We are internally discussing about the reported feature query to include in our next ReportServer release. 
Hence the response is delayed from our side.    
 
1) How do I set up the formatting of the DateTime? Does it depend on the system regional settings? If so, it is not doing so for all parts! On the Report Server I am currently using German Location and Formats which means "dd.mm.yyyy". Somehow the value which has to be entered via report parameter only accepts mm/dd/yyyy

If I try to enter sth. like 15/9/2017 it does not work because there is no month 15 and so I cannot enter all needed values.
 
Our ReportViewer DateTime parameter is rendered based on ReportViewer control culture format and it does not depend on the system regional settings. If we have to change the date format of the parameter, then we need to modify the ReportViewer locale property to required culture. 
 
Currently, we don’t have option to change the ReportViewer culture based on ReportServer culture. We have already logged feature request on this it will be included in any of our next ReportServer release.   
 
BUT the report itself displays the passed parameter value in the German format although I do not apply any kind of format string - see image below: 
 
In the textbox items process we have used the culture info class to display the value in machine culture format. So, the values in the report is displayed in German culture at your end.    
The DateTime format of the ReportDesigner and the web site (after saving the RDL file on the server) is not the same. What are the system settings which have an influence on this formatting? 
 
I have set default values for the two DateTime parameters but I still have have to enter values manually. For example I have used the value =Today() for the start parameter, but it simply does not work. When entering a default value in SSRS this value will be used for the initial data request but it seems the your ReportServer acts differently. What could be the reason for this? 
The mentioned problem occurs when the Report parameter is rendered in “en-us” culture format by default in ReportServer. If we have to change the date format of the parameter, then we should render the report for particular culture by using localization in ReportServer. As informed above, we don’t have option to change the ReportViewer culture based on ReportServer culture, this will be resolved once the feature has been included in our control. 
 The parameter says "DateTime" but I am only able to enter a date without the time part. Where can I adjust this? 
Currently, our ReportViewer control renders the Date Picker control in parameter block as per RDL ReportViewer standard design. We have considered your request to provide DateTime picker support in our ReportViewer control for parameter and logged feature report for “Provide DateTime picker for Report parameter” and it will be available in any of our next ReportServer release. 
 
Regards, 
Yuvaraj D. 


Nellinger
Replied On September 12, 2017 12:37 PM

Thanks for you answer.

Generally speaking, I really like the SyncFusion package, but the ReportDesigner somehow seems "not ready" yet and too buggy to me!

Nevertheless: Can you help me to figure out a workaround for the DatePicker problem (question 1)!? As the report parameter expects mm/dd/yyyy but the report itself handles it as dd/mm/yyyy I am not able to enter a value for the tomorrow for example and therefore this report is useless to us - if I only can use it for a third of each month (until the 12th). Do you have any idea on how to fix that? Changing the OS's regional settings is unfortunately not an option!

To question 3) SSRS supports DateTimePicker since a couple of years and for us this option is essential, as it is a basic filter criteria for most of our reports. Therefore we would highly appreciate it if you could enhance this feature.

Thanks!



Yuvaraj Devarajan [Syncfusion]
Replied On September 13, 2017 04:35 AM

Hi Björn, 
 
Thanks for the update. 
 
Nevertheless: Can you help me to figure out a workaround for the DatePicker problem (question 1)!? As the report parameter expects mm/dd/yyyy but the report itself handles it as dd/mm/yyyy I am not able to enter a value for the tomorrow for example and therefore this report is useless to us - if I only can use it for a third of each month (until the 12th). Do you have any idea on how to fix that? Changing the OS's regional settings is unfortunately not an option! 
We have provided the workaround support to load the report parameter based on locale culture. Please follow the below steps to apply the fix in your Report Server Application.  
 
1.Ensure to stop the Report Server application from the desktop shortcut – “Stop Syncfusion Report Server”.  
 
2.Download your required culture script from the below link.  
 
3. Paste the downloaded culture script into the below location.  
    {{InatalledLocation}}:\Program Files (x86)\Syncfusion\Report Server\ReportServer.Web\ Scripts\EssentialJS\i18n  
 
4. Refer the pasted file in the “i18n” folder to “ReportViewer.cshtml” file like below from the below location.  
    {{InatalledLocation}}:\Program Files (x86)\Syncfusion\Report Server\ReportServer.Web\Views\FileRender  
 
  
 
5. Now set the locale property in ReportViewer control render page that is “ReportViewer.cshtml” page like below,  
 
   
 
6. Start the Report Server Application from the desktop shortcut – “Start Syncfusion Report Server”.  
 
To question 3) SSRS supports DateTimePicker since a couple of years and for us this option is essential, as it is a basic filter criteria for most of our reports. Therefore we would highly appreciate it if you could enhance this feature. 
 
We will consider your feature request of "Need to provide DateTime picker support in our Report parameter" for next Report platform release.

 
 
Regards, 
Yuvaraj D. 


CONFIRMATION

This post will be permanently deleted. Are you sure you want to continue?

Sorry, An error occured while processing your request. Please try again later.

You are using an outdated version of Internet Explorer that may not display all features of this and other websites. Upgrade to Internet Explorer 8 or newer for a better experience.

;