Hi, есть приложение, которое может работать с разными SQL серверами(Interbase/Firebird, MSSQL, DB2, Oracle) (через свои обертки). Запросы формируются в текстовой форме и потом выполняются (т.е. через параметры не вариант). Нужно как-то работать с датой, чтоб все сервера понимали. Т.е. запрос типа

"select * from MyTable where (Date < '10.05.2005')"

чтоб выполнялся на всех серверах нормально вне зависимости ни от локали ни от чего. С MSSQL в этом отношении, как я понял, проблем нет - YYYYMMDD формат рулит... А как дела с остальными ?

Перерыл интернет, пока такое впечатление, что како-го не зависимого от типа сервера и локали формата представления даты/времени нет. На дворе 21 век, куча стандартов, а сервера не реализовали у себя какой-то общий формат, независящий от локалей и т.п. ??? Не верю... Хотя не удивлюсь, если и так - каждый на себя тянет одеяло(хоть и ругают MS, но часто у них можно найти нужное а у других нет..).

Спасибо за помощь

Станислав C.
У меня в Oracle приведенный запрос:

select * from MyTable where (Date < '10.05.2005')

сработал без проблем... Причем именно в таком написании... Хотя есть, конечно, всякие функции преобразования, например, TO_DATE()...

Я привел этот селект как пояснение. То, что у вас все ОК, скорее всего значит что локаль на сервере совпадает с тем, что вы написали. Правда сервак ИМХО может принять эту дату и как 10 мая так и 5 октября(в сша по-моемому дни и месяцы не так как у нас)



pavelvpЧерез какой интерфейс работаете? В ODBC и OLEDB для этого предусмотрены специальные escape-последовательности типа:

{d 'value'}
{t 'value'}
{ts 'value'}

Также предусмотрены ESC-последовательности для GUID, интервальных литералов, для LIKE, внешних соединений, скалярных функций и процедур.
Правда не все их поддерживают в полном объёме, но уж для дат точно должно работать.

В том то и дело, что ищу "общий" стандарт.. если он есть конечно. Для коннекта с конкретным сервером может использоваться что угодно (напр. для MSSQL OLEDB, а для Oracle какие-нибудь родные компоненты, а для Interbase/Firebird тоже свои какие-нить. Мне многого не нужно. Мне не нужно выполнять какие-то хитрые запросы. Элементарные select, insert, update. Все. Я знаю, что выполнив
slect name from table
я получу результат с любого сервера.. но вот с датой - лажа получается.



White OwlПопробуй и узнаешь :)
Чаще всего прокатывает формат YYYY-MM-DD.
В конце концов, твой клиент может иметь у себя специальную настройку для какой базы какой формат использовать.

А "чаще" это как ? На чем не прокатывает ? Чтоб попробовать нужно наставить всех серваков и играться с локалями на каждом. Хотелось вот у знающих людей поспрашать сначала... Хотя че-то по откликам люди тоже не в курсе...

Не уж то я такой особенный и хочу чего-то непонятного :-)

tru55Кроме Oracle других не знаю, но в Oracle единственная гарантия правильного восприятия - to_date('10.05.2005', 'dd.mm.yyyy'), остальное зависит от настроек

Скажите, пожалуйста, а в Run-Time как-то можно для ораклавской сессии вначале задать формат передачи даты или нет ? (т.е. как в MSSQL например "SET DATEFORMAT dmy")

tru55 FILINSQL tru55Кроме Oracle других не знаю, но в Oracle единственная гарантия правильного восприятия - to_date('10.05.2005', 'dd.mm.yyyy'), остальное зависит от настроек

Скажите, пожалуйста, а в Run-Time как-то можно для ораклавской сессии вначале задать формат передачи даты или нет ? (т.е. как в MSSQL например "SET DATEFORMAT dmy")

ALTER SESSION SET NLS_DATE_FORMAT='dd.mm.yyyy'

после этого можно со 100% гарантией передавать '10.05.2005' в качестве значения для date в sql запросе ?

pavelvp FILINSQLВ том то и дело, что ищу "общий" стандарт.. если он есть конечно. ODBC или OLEDB не общий стандарт что ли?
Для коннекта с конкретным сервером может использоваться что угодно (напр. для MSSQL OLEDB, а для Oracle какие-нибудь родные компоненты, а для Interbase/Firebird тоже свои какие-нить. Мне многого не нужно. Мне не нужно выполнять какие-то хитрые запросы. Элементарные select, insert, update. Все. Я знаю, что выполнив
slect name from table
я получу результат с любого сервера.. но вот с датой - лажа получается.
...
Не уж то я такой особенный и хочу чего-то непонятного :-)
Повторяю ещё раз. Правильно написанное приложение, использующее в качестве интерфейса доступа ODBC или OLEDB, решит эти проблемы. Нужно соблюдать два правила:
1) в запросах использовать ESC-последовательности
2) данные получать не в строку, а в соответсвующий тип данных ODBC/OLEDB.
Это типы: SQL_TYPE_TIMESTAMP, SQL_TYPE_DATE, SQL_TYPE_TIME. Для этих типов определены соответствующие структуры данных: TIMESTAMP_STRUCT, DATE_STRUCT, TIME_STRUCT.

Кхм.. Спасибо, конечно, за комментарии... Но я тоже, повторяю еще раз : используются _разные_ технологии для коннекта к каждому конкретному серверу. Меня не нужно переубеждать в чем-то. То, что я спросил - то я и хотел узнать. Спасибо еще раз.

pavelvp...И я тебе ответил - правильно делаешь, что не веришь. Такие стандарты и форматы есть, и все нормальные серверы их поддерживают аж с прошлого века :-) Уж больше 10-ти лет как :-)
А то, что прикладуха об этом не знает, так это проблемы этой прикладухи, а не конкретного сервера. Вот это я и хотел сказать.

иными словами, могу ли я в элементарном запросе

select field1 from table1 where (datefiled < xxxxxx)

вместо xxxxxx написать такое представление даты, чтоб запрос корректно обрабатывался на всех(перечисленных) серверах вне зависимости от настроек локали на них?

Если да - то это и будет "поддерживают". А если нет, и я должен извращаться для такого элементарного запроса с какими-то спец. последовательностями зная тонкости интерфейса доступа (а если решим сменить интерфейс?)- то такая поддержка и гроша выеденного не стоит.

"Поддерживают" в моем понимании, это скажем когда все сервера понимают запись в четком виде yyyymmdd, или все сервера знают такой формат вне зависимости ни от чего yyyy-mm-dd. Все хочу ошибиться, но пока меня убеждают в обратном...

tru55И, к слову сказать, в Oracle формат по умолчанию - DD-MON-YY, т.е. месяц - тремя буквами

ответьте, пожалуйста, на мой предыдущий вопрос о 100%-ти работы в случае установки формата для сессии