Oracle version:
Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production
Test:
select TO_DATE('2022.02.21','YYYY-MM-DD') from dual; --- convert success
select TO_DATE('20220221','YYYY-MM-DD') from dual; --- convert success
select TO_DATE('2022/02/21','YYYY-MM-DD') from dual; --- convert success
Why dateStr and dateFmt using different date format can work well in Oracle TO_DATE( dateStr, dateFmt)?
Oracle will ignore punctuation characters:
String-to-Date Conversion Rules
The following additional formatting rules apply when converting string values to date values (unless you have used the FX or FXFM modifiers in the format model to control exact format checking):
You can omit punctuation included in the format string from the date string if all the digits of the numerical format elements, including leading zeros, are specified. For example, specify 02 and not 2 for two-digit format elements such as MM, DD, and YY.
You can omit time fields found at the end of a format string from the date string.
You can use any non-alphanumeric character in the date string to match the punctuation symbol in the format string.
If a match fails between a datetime format element and the corresponding characters in the date string, then Oracle attempts alternative format elements, as shown in Table 2-20.
Table 2-20 Oracle Format Matching
Original Format Element
Additional Format Elements to Try in Place of the Original
'MM'
'MON' and 'MONTH'
'MON'
'MONTH'
'MONTH'
'MON'
'YY'
'YYYY'
'RR'
'RRRR'
Unless you use the FX format modifier:
FX
Format exact. This modifier specifies exact matching for the character argument and datetime format model of a TO_DATE function:
Punctuation and quoted text in the character argument must exactly match (except for case) the corresponding parts of the format model.
The character argument cannot have extra blanks. Without FX, Oracle ignores extra blanks.
Numeric data in the character argument must have the same number of digits as the corresponding element in the format model. Without FX, numbers in the character argument can omit leading zeros.
When FX is enabled, you can disable this check for leading zeros by using the FM modifier as well.
If any portion of the character argument violates any of these conditions, then Oracle returns an error message.
For example, given the queries:
select TO_DATE('2022.02.21','fxYYYY-MM-DD') from dual;
select TO_DATE('20220221','fxYYYY-MM-DD') from dual;
select TO_DATE('2022/02/21','fxYYYY-MM-DD') from dual;
select TO_DATE('2022-02-21','fxYYYY-MM-DD') from dual;
Then only the last one will work and the first 3 will raise the exception:
ORA-01861: literal does not match format string
db<>fiddle here
Related
I get the error message: ORA-01843: not a valid month after executing a sql plus script.
I try using the "standard" date format yyyy-mm-dd.
Is SQL/PL not understanding the alter session statement?
set linesize 200
set pagesize 1000
alter session set NLS_NUMERIC_CHARACTERS = ',.';
alter session set NLS_DATE_FORMAT = 'yyyy-mm-dd';
select
*
from my_table
where
date >= '2019-08-31';
exit
What you do need - from my point of view - is not to compare date values to strings.
Presuming that date here actually represent a DATE datatype column (why didn't you post table description?) (as already commented, you can't name a column that way, not unless you enclosed its name into double quotes), then
where date >= '2019-08-31'
---- ------------
DATE this is a string
datatype
Use date literal, which always has a DATE keyword and date in format 'yyyy-mm-dd':
where date >= date '2019-08-31'
Or, use to_date function with appropriate format mask:
where date >= to_date('2019-08-31', 'yyyy-mm-dd')
If date column (wrong name, as we already know) actually contains strings and you hope all of them are following the 'yyyy-mm-dd' format, well, some values don't. Storing dates into varchar2 datatype column is almost always a bad idea. Nobody prevents you from storing e.g. '2019-ac-31' into it, and that isn't a valid date value.
How can I convert this string date to datetime in oracle.
2011-07-28T23:54:14Z
Using this code throws an error:
TO_DATE('2011-07-28T23:54:14Z', 'YYYY-MM-DD HH24:MI:SS')
How can this be done?
Error report:
SQL Error: ORA-01861: literal does not match format string
01861. 00000 - "literal does not match format string"
*Cause: Literals in the input must be the same length as literals in
the format string (with the exception of leading whitespace). If the
"FX" modifier has been toggled on, the literal must match exactly,
with no extra whitespace.
*Action: Correct the format string to match the literal.
Update:-
TO_DATE('2011-07-28T23:54:14Z', 'YYYY-MM-DD"T"HH24:MI:SS"Z"')
I only see the date not time in the column
28-JUL-11
Try this:
TO_DATE('2011-07-28T23:54:14Z', 'YYYY-MM-DD"T"HH24:MI:SS"Z"')
Hey I had the same problem. I tried to convert '2017-02-20 12:15:32' varchar to a date with TO_DATE('2017-02-20 12:15:32','YYYY-MM-DD HH24:MI:SS') and all I received was 2017-02-20 the time disappeared
My solution was to use TO_TIMESTAMP('2017-02-20 12:15:32','YYYY-MM-DD HH24:MI:SS') now the time doesn't disappear.
You can use a cast to char to see the date results
select to_char(to_date('17-MAR-17 06.04.54','dd-MON-yy hh24:mi:ss'), 'mm/dd/yyyy hh24:mi:ss') from dual;
I have data in the date column as below.
reportDate
21-Jan-17
02-FEB-17
I want to write a query to fetch data for 01/21/2017?
Below query not working in Oracle.
SELECT * FROM tablename where reportDate=to_date('01/21/2017','mm/dd/yyyy')
What is the data type of reportDate? It may be DATE or VARCHAR2 and there is no way to know by just looking at it.
Run describe table_name (where table_name is the name of the table that contains this column) and see what it says.
If it's a VARCHAR2 then you need to convert it to a date as well. Use the proper format model: 'dd-Mon-rr'.
If it's DATE, it is possible it has time-of-day component; you could apply trunc() to it, but it is better to avoid calling functions on your columns if you can avoid it, for speed. In this case (if it's really DATE data type) the where condition should be
where report_date >= to_date('01/21/2017','mm/dd/yyyy')
and report_date < to_date('01/21/2017','mm/dd/yyyy') + 1
Note that the date on the right-hand side can also be written, better, as
date '2017-01-21'
(this is the ANSI standard date literal, which requires the key word date and exactly the format shown, since it doesn't use a format model; use - as separator and the format yyyy-mm-dd.)
The query should be something like this
SELECT *
FROM table_name
WHERE TRUNC(column_name) = TO_DATE('21-JAN-17', 'DD-MON-RR');
The TRUNC function returns a date value specific to that column.
The o/p which I got when I executed in sqldeveloper
https://i.stack.imgur.com/blDCw.png
Given the table ATABLE with a field AFIELD of type CHAR(8), and where i have a field with value "1234567 "
Why, in SQL Developer, if I query:
SELECT * FROM ATABLE WHERE AFIELD = '1234567';
It will automatically pad the missing space and return the results, and if I query with :
SELECT * FROM ATABLE WHERE AFIELD = :value;
and input the value, it wont ?
From the documentation:
Within expressions and conditions, Oracle treats text literals as though they have the data type CHAR by comparing them using blank-padded comparison semantics.
When you do WHERE AFIELD = '1234567' the text literal '1234567' is treated as char and blank-padded comparison semantics are used to compare the column value and the literal. Even though the literal doesn't have the trailing space, those semantics see them as the same, so it finds a match.
When you use a bind variable the literal you assign to it is a char, but the bind variable itself is varchar2 - even if you declare it as char, oddly, though in that case the value is blank-padded anyway:
var char_value char(8);
exec :char_value := '1234567';
var varchar2_value varchar2(8);
exec :varchar2_value := '1234567';
select dump('1234567') as d1, dump(:char_value) as d2, dump(:varchar2_value) as d3
from dual;
D1 D2 D3
------------------------------------ ------------------------------------ ------------------------------------
Typ=96 Len=7: 49,50,51,52,53,54,55 Typ=1 Len=8: 49,50,51,52,53,54,55,32 Typ=1 Len=7: 49,50,51,52,53,54,55
The text literal is data type 96 (char), while both bind variables are type 1 (varchar/varchar2); but notice the char_value bind variable has the trailing space, with length 8 and the last character as code point 32.
When you compare your char column value with a varchar2 bind variable the column value is implicitly converted from char to varchar2:
The following rules govern implicit data type conversions:
During SELECT FROM operations, Oracle converts the data from the column to the type of the target variable.
So your space-padded char(8) column value is implicitly converted to varchar2(8) to match the bind variable's data type, and then because they are varchar2 the nonpadded comparison semantics are used.
When you compare your char(8) column with the supposedly-char(8) bind variable, you're actually comparing with a padded varchar2(8) - but both the implicitly converted column value and the blank-padded bind variable are actually the same, both with the trailing space; '1234567 ' is the same as '1234567 ', so there is a match, even with nonpadded comparison semantics.
With the varchar2(8) bind variable the same thing happens, but now the bound value is not padded, and as you are using nonpadded comparison semantics to compare '1234567 ' with '1234567' - they are not the same, so there is no match, and no data is returned by the query.
As #a_horse_with_no_name said you should almost always use varchar2 rather than char. But if you must use it and are stuck with it then at least make sure you use the same data type for comparisons.
You are right
SELECT * FROM ATABLE WHERE AFIELD = :value;
does not work with CHAR as you desire.
Anyway I have noticed that the following query works as you desire:
SELECT * FROM ATABLE WHERE AFIELD = &value;
If you use &value in several places, you can use &&value (double &) the first time (and &value elsewhere),
in order to avoid to input the same value several times;
when you have to change that value, you can undefine it with:
undef value;
How do I specify character literals in a date specification? In the second example, I would like to skip the T and Z.
select to_date('2015-04-06 19:56:30', 'YYYY-MM-DD HH24:MI:SS') from dual;
2015-04-06 19:56:30
select to_date('2015-04-06 19:56:30', 'YYYY-MM-DDTHH24:MI:SSZ') from dual;
ORA-01821: date format not recognized
You can enclose the literals in double quotes:
SQL> select to_date('2015-04-06T19:56:30Z', 'YYYY-MM-DD"T"HH24:MI:SS"Z"') from dual;
TO_DATE('2015-04-0
------------------
06-APR-15
From the documentation,
Punctuation and Character Literals in Datetime Format Models
You can include these characters in a date format model:
Punctuation such as hyphens, slashes, commas, periods, and colons
Character literals, enclosed in double quotation marks
These characters appear in the return value in the same location as
they appear in the format model.
Following the documentation, enclosing the character literals in double-quotation marks will work in the format model.
TO_DATE('2015-04-06T19:56:30Z', 'YYYY-MM-DD"T"HH24:MI:SS"Z"')