|
|
|
|
Re: query Dead Slow [message #659523 is a reply to message #659522] |
Fri, 20 January 2017 05:17 |
cookiemonster
Messages: 13963 Registered: September 2008 Location: Rainy Manchester
|
Senior Member |
|
|
If transaction_date is a string then converting p_edt to the same format isn't going to work unless that format is YYYYMMDD ( + HH24:MI:SS if time is relevant). If it's any other format the < will give the wrong results.
|
|
|
Re: query Dead Slow [message #659529 is a reply to message #659523] |
Fri, 20 January 2017 05:55 |
|
FDAVIDOV
Messages: 20 Registered: December 2014
|
Junior Member |
|
|
Cookiemonster, of course you are right, but it would be fair to assume that the string is NOT simply 8 digits in the form "YYYYMMDD" but something more unambiguous, like "12-Feb-2017", which does not require a format specification. Moreover, I can't testing right now, but I doubt PL/SQL would cope with such conversion without a format specification.
In any case, my message to the OP is: do NOT case a column from the table to the format of the parameter, but do it the other way round (if possible of course).
Having said that, and based on the (poor) available information, I still think the OP should try my suggestion.
|
|
|
Re: query Dead Slow [message #659530 is a reply to message #659529] |
Fri, 20 January 2017 06:02 |
John Watson
Messages: 8964 Registered: January 2010 Location: Global Village
|
Senior Member |
|
|
Quote: something more unambiguous, like "12-Feb-2017", which does not require a format specification. that most certainly does require a format specification. In my case, for example, the conversion works but gives a date of five o'clock in the afternoon back in the days of Emperor Augustus:
orclz>
orclz> select to_date('12-Feb-2017') from dual;
TO_DATE('12-FEB-201
-------------------
0012-02-20:17:00:00
orclz>
orclz>
|
|
|
Re: query Dead Slow [message #659534 is a reply to message #659530] |
Fri, 20 January 2017 06:34 |
cookiemonster
Messages: 13963 Registered: September 2008 Location: Rainy Manchester
|
Senior Member |
|
|
As long as the format matches the default nls_date_format it won't matter what it is (as long as users don't go around changing it, which they might).
However, it might be the OP is using to_date to do what trunc does, I keep coming across people doing that.
@annu-agi - if transaction_date is actually a date and you're trying to get rid of the time part for comparison purposes, use trunc instead, that's why it exists.
|
|
|
|
|