【发布时间】:2021-10-08 04:19:04
【问题描述】:
在我们的package 中,我们有where 子句,如下所示。
pp.start_date >= nvl(TO_DATE('01-JAN-2018', 'RRRR/MM/DD HH24:MI:SS'), pp.start_date)
它在客户环境中运行良好。但由于格式是'RRRR/MM/DD HH24:MI:SS',所以我们更改了日期,如下所示。
pp.start_date >= nvl(TO_DATE('2018/01/01', 'RRRR/MM/DD HH24:MI:SS'), pp.start_date)
理想情况下它应该可以工作,因为我们已经给出了正确的格式。在第一种情况下,它返回 679 行,但在第二种情况下,它返回 0 行。我们有 679 个正确的行数。
第二个 NVL 命令有什么问题?
【问题讨论】:
-
技术上我不认为
RRRR是一个有效的修饰符。RR旨在将 2 位数的年份向上或向下舍入以获得正确的世纪。如果您已有 4 位数年份,请使用YYYY。 -
我也检查了 YYYY RR 但只有当我使用 DD-MON-YYYY 格式的日期时才会输出。
-
请提供可重现的示例。您所说的在技术上或逻辑上都不正确。如果
RRRR给了你一些东西,它并不能保证它是正确的 -
我看不出
TO_DATE('01-JAN-2018','RRRR/MM/DD HH24:MI:SS')怎么可能“完美运行”。这给了我20-JAN-2001 18:00:00。另外,既然可以使用标准的date literal,为什么还要硬编码任何TO_DATE表达式?
标签: sql oracle oracle11g oracle12c