Oracle 日期格式 - 奇怪的行为
我正在编写一个 SQL 查询来从两个日期之间的表中检索数据。我给出了两个输入,如图所示。我将日期转换为 TO_CHAR(DD/MON/YYYY)。
1. StartDate > 01/SEP/2009
EndDate < 01/OCT/2009
2. StartDate > 01/SEP/2009
EndDate < 1/OCT/2009
我没有得到第一个输入的任何结果。当我将其更改为第二个时,我得到了结果。 01/OCT/2009 和 01/OCT/2009 之间有什么区别? 2009 年 10 月 1 日?
I am writing a SQL query to retrieve data from a table between two dates. I give two inputs as shown. I convert the Date TO_CHAR(DD/MON/YYYY)
.
1. StartDate > 01/SEP/2009
EndDate < 01/OCT/2009
2. StartDate > 01/SEP/2009
EndDate < 1/OCT/2009
I don't get any result for the first input. When I change it to second one, I get the result.
What is the difference between 01/OCT/2009 & 1/OCT/2009 ?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
比较日期时,您应该始终将运算符两侧显式转换为 DATE 数据类型。假设 StartDate 和 EndDate 都是 DATE 数据类型,这将起作用:
但是在您的情况下,您得到的结果与 VARCHAR 比较一致。您正在比较字符串,并且您不太可能得到正确的结果(例如,因为月份不是按字母顺序排序的)。
如果 StartDate 和 EndDate 确实是 VARCHAR,您应该显式地转换它们:
这对于所有版本的 Oracle 都有效。
when comparing dates you should always convert explicitely both sides of the operator to DATE datatype. Assuming StartDate and EndDate are both DATE datatype, this would work:
In your case however the result you get is consistent with VARCHAR comparison. You're comparing strings and it's VERY unlikely you will get the correct result (since months are NOT sorted alphabetically for instance).
If StartDate and EndDate are indeed VARCHAR you should convert them explicitely:
This is valid for all versions of Oracle.
由于我没有可用于验证我的答案的 Oracle 客户端,因此不确定:在 Oracle 中,表示日期 (D) 的日期字符串中的单个数字用于指定星期几(周一至周日), 2 位数字用于指定月份中的日期(3 位数字表示一年中的日期)。尽管您提到您正在使用看似正确的解释方法来转换字符串,但我认为这可能是问题的根源(或者至少可能是对差异的解释......)。
Since I don't have an Oracle client available to verify my answer, it's not certain but: In Oracle, a single digit in the date string representing the day (D) is used to specify the day of week (Monday-Sunday), while 2 digits are used to specify the day of month (3 digits will represent the day in the year). Although you mentioned you're converting the string using what seems like the right way to do the interpretation, I think this could be the source of the problem (or at least could be an explanation to the difference..).