Как правильно указал APC, ваш столбец start_date выглядит как TIMESTAMP, но это может быть также TIMESTAMP с локальным TIMEZONE или TIMESTAMP с TIMEZONE типом данных. Это может оказать влияние на любые запросы, которые вы выполняете к данным, если ваш сервер баз данных находится в другом часовом поясе. Однако давайте будем простыми и предположим, что вы находитесь в том же часовом поясе, что и ваш сервер. Во-первых, чтобы дать вам уверенность, проверьте, что start_date является типом данных TIMESTAMP.
Используйте команду SQLPlus DESCRIBE (или эквивалент в вашей IDE), чтобы убедиться, что этот столбец является типом данных TIMESTAMP.
например
ОПИСАТЬ mytable
Должен сообщить:
Name Null? Type
----------- ----- ------------
NAME VARHAR2(20)
START_DATE TIMESTAMP
Если он указан как Type = TIMESTAMP, вы можете запросить диапазоны дат с самым простым преобразованием даты TO_TIMESTAMP, для которого не требуется аргумент (или картинка).
Мы используем TO_TIMESTAMP, чтобы оптимизатор рассмотрел любой индекс в столбце START_DATE. В ответе APC также отмечалось, что для этого столбца мог быть создан индекс на основе функций, и это могло бы повлиять на предикат SQL, но мы не можем комментировать это в этом запросе. Если вы хотите узнать, как узнать, какие индексы были применены к таблице, опубликуйте еще один вопрос, и мы ответим на него отдельно.
Итак, при условии, что для start_date имеется индекс, который является типом данных TIMESTAMP, и вы хотите, чтобы оптимизатор его учел, ваш SQL будет:
select * from mytable where start_date between to_timestamp('15-JAN-10') AND to_timestamp('17-JAN-10')+.9999999
+. 999999999 очень близко к, но не совсем 1, поэтому конверсия 17-ЯНВ-10 будет в этот день как можно ближе к полуночи, поэтому вы запрашиваете обе строки.
База данных будет видеть МЕЖДУ с 15-JAN-10 00: 00: 00: 0000000 до 17-JAN-10 23: 59: 59: 99999 и будет поэтому включите все даты с 15, 16 и 17 января 2010 года независимо от временной составляющей временной метки.
Надеюсь, это поможет.
Dazzer