parameter date format - change to dd/mm/yyyy

Hi All,

I'm using report with a date parameter (user enters a date) and all transactions before that date are displayed. I don't know how to set parameter date format on the displayed report to dd/mm/yyyy.

If it's not a parameter I usually use sql " convert(varchar(10),datefield,103)" but don't know how to use this with parameter.

Thanks

Sonny

Pretty much the same whether for a parameter or for a field expression:

Code Snippet

=Format(Fields!last_edit.Value,"d/M/yyyy")

=Format(Parameters!RPDate.value,"d/M/yyyy")

that should do it.... watch the case-sensitivity; a lower case "m" gives you minutes, not months...

One thing, though: if the user enters the date param directly, you might want to do a cast, something like this just in case there is a data type issue somewhere (of course you might have to do this for whatever code actually *uses* the param as well, I don't know, so maybe it's a dumb thought)

Code Snippet

=Format(CDATE(Parameters!RPDate.value),"d/M/yyyy")

>L<

|||

Hi Lisa,

thanks for the answer. this works with date picker but if I enter the date manually it does not. maybe i have to convert date as you said.

basicall current report paramater is such that you must enter date as YYYYMMDD format. I guess this is default SQL server date format.

I'm on RS patch 0 , never been able to use date picker.

Sonny

|||

WHen you enter the date manually, what does it look like (I'm not asking what the result of the expression is -- I'm asking what you actually enter)?

It's not so much that it has to match the "default sql server date format" as it has to match *some* default, which could be the locale on the server, I'm really not sure.

It is not a big deal to write some code to make sure that your manually-entered date is properly parsed into the format that you want. HOWEVER the reason I just suggested the cast, rather than parsing code, is that you run into the problem of other people maybe entering the manually-entered date differently than you do and possibly parsing out for many different cases.

Since, as you say, the server does have an internal idea of what a date should look like, I find it's often best to write something that does a cast and lets the server figure it out if it can. The worst that will happen is that you'll see #ERROR instead of the expected result, but often SQL Server is pretty smart about figuring out dates, and some of the .NET classes at work in RS (which probably aren't even in SQL Server at the point they are doing this work) may be smart about it also.

If the cast doesn't work, we will proceed further <s>.

>L<