Monday, March 19, 2012

Datetime Parameter

I have deployed a report which accepts a from and to date parameter, the
report links to another report based upon the contents of the cell which is
selected and passes the cell content and the 2 date parameters to the next
report.
Now this is all fine however when the date is passed to the second report it
appears as non en-GB. i.e. I am passing 07/01/2006 (7th of January 2006)
which on the second report becomes 1st July 2006. Passing a date such as the
14th January returns an invalid date error (no 14th month).
I have got around the error by accepting the date into the second report as
a string, however the dates appear (from my perspective) incorrectly
formatted and I can't have a datetime picker.
Incidentally if I change the second reports parameter back to datetime the
date pickers appears correctly and work as expected. Both reports are
formatted en-GB.
Does any one know where I am going wrong?
--
Regards
Darren FranceWhat is the language of the Report set to?
Have you tried explicitly converting the value passed in the Jump To.
ie =Convert.ToDateTime(Parameters!DateParam.Value) ?
Andy Potter|||If I change the parameter back to datetime (with or without the explicit
convert) I get the following error with the dates 08/01/2006 and 15/01/2006
(8th and 15th January:
The value provided for the report parameter 'UserEndDate' is not valid for
its type. (rsReportParameterTypeMismatch)
All reports are set to English (United Kingdom)
XML: <Language>en-GB</Language>
I should have pointed out (my apologies for not doing so) is that I am using
Microsoft SQL Server Reporting Services Designers Version 9.00.1399.00
(2005). Deploying to a server with Reporting Services 2005 but with SQL 7.0
(SP4) as both the report database host and data source.
Regards
Darren France
"Potter" wrote:
> What is the language of the Report set to?
> Have you tried explicitly converting the value passed in the Jump To.
> ie => Convert.ToDateTime(Parameters!DateParam.Value) ?
> Andy Potter
>|||Darren,
I tried to reproduce this error and I cannot.
How are you passing parameters to the second report? Are you using the
Jump To navigation?
Andy Potter|||I am using jump to navigation, and passing: =Parameters!<parameter>.Value
I have also tried the convert.todate and also splitting the date into it's
constituant parts (day, month, year) and converting back to a date. If I add
textboxes with the parameter(s) value in it, it is correct on the first
report but appears in the wrong format on the second report (which is what I
expected but wanked to make sure it was not the date time picker).
I have also explicitly converted the date parameter in the stored procedure
- convert(smalldatetime, <parameter>, 103). But given that I am not passing a
date back as part of the query, and the reports work individually (i.e.
without the parameter passing) I don't think this affecting the results.
I have just double checked that the regional settings of both my machine and
the server (data source and report source) are correct.
I have noticed that previewing the report within the designer errors even on
the source report. I have been through the options in visual studio and
provided I avoid clicking on the 'data customisation ui' which results in a
nice error and a restart of visual studio, I personally cannot find anything
which could be causing this and I am out of ideas.
Regards
Darren France
"Potter" wrote:
> Darren,
> I tried to reproduce this error and I cannot.
> How are you passing parameters to the second report? Are you using the
> Jump To navigation?
> Andy Potter
>|||I set up the same scenario without a problem.
2 Reports. Each have a parameter called gbdate and a single textbox
with a value of parameters!gbdate.value. The first report has a
navigation jump to to the second report, passing the param value to the
second report. Both reports have a language of en-GB.
One thing I did notice. Unless you have your browser language set to
en-GB, you won't see the date value in the parameter selection textbox
in the dd/mm/yyyy format.
Andy Potter|||I ran into the same problems with the 2000 SP 2 version of RS. My only
solution was to include custom code to every report (created an empty report
with the code so I can use copy + paste) and run the code on all passed
parameters. it was like:
Type in the "Code" section of report properties:
Public Function GetISODate(tmDate as DateTime)
return tmDate.Year & "-" & tmDate.Month & "-" & tmDate.Day
End Function
and used it on the navigation:
=Code.GetISODate(Parameters!<parameter>.Value)
It seems that the ISO formatted date (year-month-day) will be parsed the
same by every culture.
"Darren France" wrote:
> I am using jump to navigation, and passing: =Parameters!<parameter>.Value
> I have also tried the convert.todate and also splitting the date into it's
> constituant parts (day, month, year) and converting back to a date. If I add
> textboxes with the parameter(s) value in it, it is correct on the first
> report but appears in the wrong format on the second report (which is what I
> expected but wanked to make sure it was not the date time picker).
> I have also explicitly converted the date parameter in the stored procedure
> - convert(smalldatetime, <parameter>, 103). But given that I am not passing a
> date back as part of the query, and the reports work individually (i.e.
> without the parameter passing) I don't think this affecting the results.
> I have just double checked that the regional settings of both my machine and
> the server (data source and report source) are correct.
> I have noticed that previewing the report within the designer errors even on
> the source report. I have been through the options in visual studio and
> provided I avoid clicking on the 'data customisation ui' which results in a
> nice error and a restart of visual studio, I personally cannot find anything
> which could be causing this and I am out of ideas.
>
> --
>
> Regards
> Darren France
>
> "Potter" wrote:
> > Darren,
> >
> > I tried to reproduce this error and I cannot.
> >
> > How are you passing parameters to the second report? Are you using the
> > Jump To navigation?
> >
> > Andy Potter
> >
> >|||I have the same problem. One report has default datetime parameters. It uses
the navigation feature to call a second report, with the same parameters
passed to the second report. In the designer this works fine but when
deployed the second report crashes with an rsReportParameterTypeMismatch
error.
This only happens when the dates being passed are non/ambiguous US/English.
In other words 6/1/06 will be passed OK 16/1/06 will not. Similarly 6-Jan-06
works, 16-Jan-06 doesn't.
So it's not really a type mismatch error but a dataconversion issue.
Any help welcome!
Bob
--
Bob
"Potter" wrote:
> I set up the same scenario without a problem.
> 2 Reports. Each have a parameter called gbdate and a single textbox
> with a value of parameters!gbdate.value. The first report has a
> navigation jump to to the second report, passing the param value to the
> second report. Both reports have a language of en-GB.
> One thing I did notice. Unless you have your browser language set to
> en-GB, you won't see the date value in the parameter selection textbox
> in the dd/mm/yyyy format.
> Andy Potter
>|||Works a treat, thank you very much.
p.s.
I would like to apologise and point out that there was a typing mistake in
my last post, it should have read 'but wanted', I was not sharing my personal
hobbies with the newsgroup. Unfortunately I cannot find a regional setting to
blame that on!
--
Regards
Darren France
"GreyMana" wrote:
> I ran into the same problems with the 2000 SP 2 version of RS. My only
> solution was to include custom code to every report (created an empty report
> with the code so I can use copy + paste) and run the code on all passed
> parameters. it was like:
> Type in the "Code" section of report properties:
> Public Function GetISODate(tmDate as DateTime)
> return tmDate.Year & "-" & tmDate.Month & "-" & tmDate.Day
> End Function
> and used it on the navigation:
> =Code.GetISODate(Parameters!<parameter>.Value)
> It seems that the ISO formatted date (year-month-day) will be parsed the
> same by every culture.
> "Darren France" wrote:
> > I am using jump to navigation, and passing: =Parameters!<parameter>.Value
> >
> > I have also tried the convert.todate and also splitting the date into it's
> > constituant parts (day, month, year) and converting back to a date. If I add
> > textboxes with the parameter(s) value in it, it is correct on the first
> > report but appears in the wrong format on the second report (which is what I
> > expected but wanked to make sure it was not the date time picker).
> >
> > I have also explicitly converted the date parameter in the stored procedure
> > - convert(smalldatetime, <parameter>, 103). But given that I am not passing a
> > date back as part of the query, and the reports work individually (i.e.
> > without the parameter passing) I don't think this affecting the results.
> >
> > I have just double checked that the regional settings of both my machine and
> > the server (data source and report source) are correct.
> >
> > I have noticed that previewing the report within the designer errors even on
> > the source report. I have been through the options in visual studio and
> > provided I avoid clicking on the 'data customisation ui' which results in a
> > nice error and a restart of visual studio, I personally cannot find anything
> > which could be causing this and I am out of ideas.
> >
> >
> > --
> >
> >
> > Regards
> >
> > Darren France
> >
> >
> > "Potter" wrote:
> >
> > > Darren,
> > >
> > > I tried to reproduce this error and I cannot.
> > >
> > > How are you passing parameters to the second report? Are you using the
> > > Jump To navigation?
> > >
> > > Andy Potter
> > >
> > >|||Hi,
what do you mean by "Used it on the Navigation"?
thanks
Matt
"GreyMana" wrote:
> I ran into the same problems with the 2000 SP 2 version of RS. My only
> solution was to include custom code to every report (created an empty report
> with the code so I can use copy + paste) and run the code on all passed
> parameters. it was like:
> Type in the "Code" section of report properties:
> Public Function GetISODate(tmDate as DateTime)
> return tmDate.Year & "-" & tmDate.Month & "-" & tmDate.Day
> End Function
> and used it on the navigation:
> =Code.GetISODate(Parameters!<parameter>.Value)
> It seems that the ISO formatted date (year-month-day) will be parsed the
> same by every culture.
> "Darren France" wrote:
> > I am using jump to navigation, and passing: =Parameters!<parameter>.Value
> >
> > I have also tried the convert.todate and also splitting the date into it's
> > constituant parts (day, month, year) and converting back to a date. If I add
> > textboxes with the parameter(s) value in it, it is correct on the first
> > report but appears in the wrong format on the second report (which is what I
> > expected but wanked to make sure it was not the date time picker).
> >
> > I have also explicitly converted the date parameter in the stored procedure
> > - convert(smalldatetime, <parameter>, 103). But given that I am not passing a
> > date back as part of the query, and the reports work individually (i.e.
> > without the parameter passing) I don't think this affecting the results.
> >
> > I have just double checked that the regional settings of both my machine and
> > the server (data source and report source) are correct.
> >
> > I have noticed that previewing the report within the designer errors even on
> > the source report. I have been through the options in visual studio and
> > provided I avoid clicking on the 'data customisation ui' which results in a
> > nice error and a restart of visual studio, I personally cannot find anything
> > which could be causing this and I am out of ideas.
> >
> >
> > --
> >
> >
> > Regards
> >
> > Darren France
> >
> >
> > "Potter" wrote:
> >
> > > Darren,
> > >
> > > I tried to reproduce this error and I cannot.
> > >
> > > How are you passing parameters to the second report? Are you using the
> > > Jump To navigation?
> > >
> > > Andy Potter
> > >
> > >

No comments:

Post a Comment