Формат даты

← →
Sam Stone © (2005-07-14 21:07) [0]

Коннекчусь к произвольной базе через ODBC. Как узнать, в каком формате хранится дата?

← →
TQuery (2005-07-14 21:10) [1]

В формате даты, установленном на компьютере, на котором запускается проект

← →
Reindeer Moss Eater © (2005-07-14 21:12) [2]

В формате даты, установленной в SQL сервере.

← →
TQuery (2005-07-14 21:17) [3]

>Reindeer Moss Eater © (14.07.05 21:12) [2]
Что-то я не углядел упоминания о SQL сервере:)

← →
Anatoly Podgoretsky © (2005-07-14 21:19) [4]

Sam Stone © (14.07.05 21:07)
Неопределено и не нужно

← →
DiamondShark © (2005-07-14 21:26) [5]

> Коннекчусь к произвольной базе через ODBC. Как узнать, в
> каком формате хранится дата?

А зачем? Всё равно получать ты её будешь в формате, установленным ODBC.

← →
Desdechado © (2005-07-14 23:01) [6]

а она в формате хранится?
даже если так, то тебе нужен формат, который тебе драйвер вернет, а также тот, к которому тебе нужно привети перед отображением

← →
sniknik © (2005-07-14 23:13) [7]

какой может быть формат у числа? целое/дробное вот и весь выбор. ;о))

> Коннекчусь к произвольной базе
будет формат произвольной базы. открываеш справку по произвольной базе и читаеш...

← →
Reindeer Moss Eater © (2005-07-14 23:17) [8]

У числа которое есть дата может быть формат хранения.
И есть.
Например можно хранить его как целое количество секунд.
Можно хранить как плавающую точку и так далее.
Это и есть формат хранения даты.

← →
sniknik © (2005-07-14 23:49) [9]

нет, это формат распознавания даты... ;о))
что понимают под конкретным числом секунда/месяц/год что обозначается под 0-м (точка отсчета), а хранятся оно одинаково.

например точка отсчета у мелкософта (mssql/access) 0 = 30.12.1899, у борманда 01.01.1900. т.е. понимают они под 0-м разные даты... а вот хранят одинаково в типе double... ноль он ноль и есть. ;)

← →
Reindeer Moss Eater © (2005-07-14 23:56) [10]

Они в Double.
Другие в целом.

Коннекчусь к произвольной базе через ODBC. Как узнать, в каком формате хранится дата?

Если ты про строковое представление даты, то используй ODBC canonical
YYYY-MM-DD
прокатит везде.

← →
Anatoly Podgoretsky © (2005-07-15 00:12) [11]

sniknik © (14.07.05 23:49) [9]
Только наоборот, Борланд когда внедрял свой формат клялся об совместимости с МС и это мол они виноваты, что им пришлось на него перейти. Но как оказалось он обманывал.

← →
sniknik © (2005-07-15 00:51) [12]

> Другие в целом.
это для тех движков что "чистую" дату позволяют например парадокс, пример был для дататайма. а если взять фокспро/дбасе то строка..., ну да у них там все строки... вот!!! понял про что вопрос, произвольная база = foxpro/dbase. вот какой формат хранения имеется в виду! ;о)))

> Только наоборот
да, точно. наоборот.
но тогда они сами запутались... в access(фактически в VB) (мелкософт!) CDate(0) дает 30.12.1899 а в mssql (мелкософт!) CAST(0 AS DateTime) 01.01.1900.
получается, меняли - обратно вернули... (???)

← →
evvcom © (2005-07-15 08:25) [13]

> Как узнать, в каком формате хранится дата?

Обычно, в числовом. А что собственно интересует?

← →
Sam Stone © (2005-07-15 14:03) [14]

Собсно формат даты нужен для составления запроса. Просто в одной базе дата лежит ddmmyyyy, в другой mmddyyyy, в третьей еще как-нибудь будет...

> Если ты про строковое представление даты, то используй ODBC
> canonical
> YYYY-MM-DD
> прокатит везде.

щас попробую... Вроде работает, буду тестить на других базах...
Спасибо.

> будет формат произвольной базы. открываеш справку по произвольной
> базе и читаеш...

это, конечно, забавно, но не подходит :) Потому как программа уже будет написана.

← →
sniknik © (2005-07-15 14:27) [15]

> Собсно формат даты нужен для составления запроса.
а чего тогда вопрос такой странный "в обход"? кода требуется вполне конкретное, нисколько не связанное с хранением. (и настолько часто задаваемое, что уже набило оскомину.)
прочитай про параметры... они гораздо универсальнее "универсального ODBC формата". ;) прям здесь на форуме поищи и почитай.

← →
DiamondShark © (2005-07-15 17:30) [16]

> Если ты про строковое представление даты, то используй ODBC
> canonical
> YYYY-MM-DD
> прокатит везде.

Не везде.

Чтоб везде, надо использовать ODBC escape sequence

{d "yyyy-mm-dd"}
{t "hh:mm:ss"}
{ts "yyyy-mm-dd hh:mm:ss.fff"}

← →
sniknik © (2005-07-15 17:58) [17]

> Чтоб везде, надо использовать ODBC escape sequence
прям сказки на ночь. ;о))

везде... не кажется вам что это слишком много где? ;о)) а если этот драйвер писал я? (а мне плевать на строковые соглашения) ;о))

берем первый (у меня) попавшийся...
делаем запрос
SELECT * FROM TODOS
WHERE SCHEDULED = {d"2001-09-20"}
получаем ответ ;о)
Dynamic SQL Error
SQL error code = -104
Token unknown - line 2, char 22
"2001-09-20"

??? че за фигня? почему ваше "весде" сдесь сбой дало ???
(можно не отвечать. риторический вопрос ;)

> а если этот драйвер писал я? (а мне плевать на строковые
> соглашения) ;о))

Поймать, и руки оторвать.

> берем первый (у меня) попавшийся...

Это кто такой? "Имя, сестра! Имя!"
Мы его к позорному столбу.

> Это кто такой? "Имя, сестра! Имя!"
в этом случае ZStyle OLEDB провайдер, подключен к файрбирд 1.5.

но я так думаю таких большинство... проверять некогда, домой иду.

> в этом случае ZStyle OLEDB провайдер, подключен к файрбирд
> 1.5.

А при чём здесь OLEDB провайдер? Мы про ODBC драйвер говорим.
Впрочем, у файрбирда ничего нормально не работает.

> но я так думаю таких большинство... проверять некогда, домой
> иду.

А вот я проверил.
Пакет микрософтовских драйверов (dbf, текстовые, парадокс, эксель)
Аксес
SQL Server
Пакет драйверов INTERSOLV (штук пятьнадцать всяких разных форматов)
Sybase ASA

Всё поддерживается.

> Мы про ODBC драйвер говорим.
тут согласен.
но тут у меня другое подозрение ;о))
что ODBC сам меняет это представление на параметр...
и вот почему.
среди упомянутых - Аксес + (dbf, текстовые, парадокс, эксель) вродебы ODBC - шных драйверов, ни один не работает сам, все они передают запрос на выполнение jet-у (OLE DB), во всяком случае в новых редакциях.
можеш проверить, выполни запрос к несушествующей таблице в том же SQL Explorer-e при подключении к ODBS DSN MS Access Database (или др. аксессовскому/перечисленному). после внимательно читай ошибку которую вернет, будет чтото вроде этого
[Microsoft][Драйвер ODBC Microsoft Access] Ядро базы данных Microsoft Jet не может найти входную таблицу или запрос "Table1". Проверьте существование таблицы или запроса и правильность имени
т.е. ошибка возврашается от того кто на самом деле запрос выполняет... а он точно не понимает тех соглашений про которые ты говориш. вывод - ему ктото подсовывает то что он понимает, параметры в данном случае. посредником является ODBC, значит он. ;)

вот. и тут подходим с другой стороны к тому же самому, зачем чтото преобразовывать подставлять это в специальную форму для того чтобы его "разпреобразовали" назад?
ведь можно это сразу в той форме дать. (в форме числа даты/датытайм) и, ни вам ни этой загадочной ;) ODBC-ине напрягаться не придется. ;о))

> sniknik © (15.07.05 21:37) [21]

> но тут у меня другое подозрение ;о))
> что ODBC сам меняет это представление на параметр...

Естественно. ODBC -- это стандарт, набор соглашений, обязательных к реализации

> среди упомянутых - Аксес + (dbf, текстовые, парадокс, эксель)
> вродебы ODBC - шных драйверов, ни один не работает сам,
> все они передают запрос на выполнение jet-у (OLE DB),

Почему "вродебы ODBC - шных"?
Ещё раз: ODBC -- это просто стандарт API.
Кстати, jet и OLE DB -- это разные вещи, и скобочки тут не в кассу. Первое -- конкретный движок, второе -- ещё одна специпикаци API.

Ты разницу между интерфейсом и реализацией понимаешь?

> вот. и тут подходим с другой стороны к тому же самому, зачем
> чтото преобразовывать подставлять это в специальную форму
> для того чтобы его "разпреобразовали" назад?

А для чего вообще создают стандарты?

> Ты разницу между интерфейсом и реализацией понимаешь?
догадываюсь. ;о)) с трудом правда.... но мне хватает.

> Почему "вродебы ODBC - шных"?
потому что они скорее OLE DB-шные, под MSSQL и access протокол разрабатывался, раз для них значит OLED DB-шные. это уж потом все этот движок стали пользовать, вон даже DAO (ни к ODBC ни OLEDB отношения не имеет) теперь Jet использует, а был самостоятельный движок, и был раньше джета.
и еще потому что Jet это COM обьекты, сделан так. и все его ISAM-ы. т.е. предполагает управление именно под OLE DB. если бы было для ODBC то это были бы просто dll-ки (думаю так, возможно ошибаюсь. но не думаю ;о))).

> Ещё раз: ODBC -- это просто стандарт API.
;о)) чтобы сказать еще раз, надо сказать это хотя бы раз... не вижу, где первый раз?
(хотя с самим утверждением спорить не буду :)

> Кстати, jet и OLE DB -- это разные вещи
типа ктото спорит?

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

Какая ужасная каша в голове...

Формат даты Найти похожие ветки