DateTime parameter switches format

The reports I am creating in a VS2005 Business Intelligence Project
have DateTime parameters. To preview reports, after the parameters have
been entered in "Preview" tab, the "View Report" button has to be
clicked.
It looks to me that whenever the "View Report" is cliked, it causes
"datetime" parameter boxes to re-oder the dates so that "mm" and "dd"
values are interchanged.
For instance, if I enter "12/02/2006" (meaning Feb 02, 2006, in
Australian format ie. dd/mm/yyyy) and click "View Report" button, the
datatime parameter is rearranged as "02/12/2006", and consequenly
producing data for Dec 02, 2006.
Strangely, If I click "view report" again, it interchanges "dd" and
"mm" values again resulting the date I originally intended and produces
the correct report. Clicking "View Report" again causes "dd" and "mm"
to interchange, and so on it goes.
If I enter "20/02/2006" in the datetime parameter box, and click "View
Report" button, I get an error message about incorrect datetime format.
"An error occured during local report processing. The value provided
for the report parameter 'dtStartDate' is not valid for its type".
So, it appears that VS2005
* expects me to input datetime as "mm/dd/yyyy" format,
* rearranges "mm" and "dd" to "dd/mm/yyyy" format (whenever "View
Report" button is clicked) before passing the parameters to the stored
procedures.
I have set the report's "Language" property to "Australia", and WinXP's
language to "Australian English"
Any suggestions and workarounds are greatly appreciated.
Thanks
SurOne thing you can do is to change the parameter type to string, where you can
control the string format of the date... The down side to this is that you do
NOT get the Date-picker window...
--
Wayne Snyder MCDBA, SQL Server MVP
Mariner, Charlotte, NC
I support the Professional Association for SQL Server ( PASS) and it''s
community of SQL Professionals.
"suranga.suranga@.gmail.com" wrote:
> The reports I am creating in a VS2005 Business Intelligence Project
> have DateTime parameters. To preview reports, after the parameters have
> been entered in "Preview" tab, the "View Report" button has to be
> clicked.
> It looks to me that whenever the "View Report" is cliked, it causes
> "datetime" parameter boxes to re-oder the dates so that "mm" and "dd"
> values are interchanged.
> For instance, if I enter "12/02/2006" (meaning Feb 02, 2006, in
> Australian format ie. dd/mm/yyyy) and click "View Report" button, the
> datatime parameter is rearranged as "02/12/2006", and consequenly
> producing data for Dec 02, 2006.
> Strangely, If I click "view report" again, it interchanges "dd" and
> "mm" values again resulting the date I originally intended and produces
> the correct report. Clicking "View Report" again causes "dd" and "mm"
> to interchange, and so on it goes.
> If I enter "20/02/2006" in the datetime parameter box, and click "View
> Report" button, I get an error message about incorrect datetime format.
> "An error occured during local report processing. The value provided
> for the report parameter 'dtStartDate' is not valid for its type".
> So, it appears that VS2005
> * expects me to input datetime as "mm/dd/yyyy" format,
> * rearranges "mm" and "dd" to "dd/mm/yyyy" format (whenever "View
> Report" button is clicked) before passing the parameters to the stored
> procedures.
> I have set the report's "Language" property to "Australia", and WinXP's
> language to "Australian English"
> Any suggestions and workarounds are greatly appreciated.
> Thanks
> Sur
>|||I had what sounds very like this problem as described in an earlier thread.
If it is the same problem, it should not occur when reports are deployed to
the report server. For me, it only occurs in development.
Ed Allison
"Wayne Snyder" <wayne.nospam.snyder@.mariner-usa.com> wrote in message
news:F8583B54-267B-40F7-B105-D450934E8F53@.microsoft.com...
> One thing you can do is to change the parameter type to string, where you
> can
> control the string format of the date... The down side to this is that you
> do
> NOT get the Date-picker window...
> --
> Wayne Snyder MCDBA, SQL Server MVP
> Mariner, Charlotte, NC
> I support the Professional Association for SQL Server ( PASS) and it''s
> community of SQL Professionals.
>
> "suranga.suranga@.gmail.com" wrote:
>> The reports I am creating in a VS2005 Business Intelligence Project
>> have DateTime parameters. To preview reports, after the parameters have
>> been entered in "Preview" tab, the "View Report" button has to be
>> clicked.
>> It looks to me that whenever the "View Report" is cliked, it causes
>> "datetime" parameter boxes to re-oder the dates so that "mm" and "dd"
>> values are interchanged.
>> For instance, if I enter "12/02/2006" (meaning Feb 02, 2006, in
>> Australian format ie. dd/mm/yyyy) and click "View Report" button, the
>> datatime parameter is rearranged as "02/12/2006", and consequenly
>> producing data for Dec 02, 2006.
>> Strangely, If I click "view report" again, it interchanges "dd" and
>> "mm" values again resulting the date I originally intended and produces
>> the correct report. Clicking "View Report" again causes "dd" and "mm"
>> to interchange, and so on it goes.
>> If I enter "20/02/2006" in the datetime parameter box, and click "View
>> Report" button, I get an error message about incorrect datetime format.
>> "An error occured during local report processing. The value provided
>> for the report parameter 'dtStartDate' is not valid for its type".
>> So, it appears that VS2005
>> * expects me to input datetime as "mm/dd/yyyy" format,
>> * rearranges "mm" and "dd" to "dd/mm/yyyy" format (whenever "View
>> Report" button is clicked) before passing the parameters to the stored
>> procedures.
>> I have set the report's "Language" property to "Australia", and WinXP's
>> language to "Australian English"
>> Any suggestions and workarounds are greatly appreciated.
>> Thanks
>> Sur
>>|||Ed and Wayne,
Thanks. I published the reports at a Reporting Server instance; it
doesn't suffer from this bug. I guess until a service pack is realised
for VS2005, I'll have to enter dates in the universal format
(yyyy-MM-dd) to overcome this bug.