Дата и время в Axapta

[nix0root]

Возможно кому-нибудь пригодится данная конструкция.

Стояла следующая проблема:

Т.к. Axapta не умеет хранить в одном поле дату и время (например 11.11.2009 22:02:33), принято хранить эту информацию в двух отдельных полях (типы полей Date и Int). Это затрудняет поиск данных по периоду.

Я решил данную проблему следующим образом (пример для Oracle):

TO_DATE(TO_CHAR(T.DATE + (T.TIME/86400), 'DD.MM.YYYY HH24:MI:SS'), 'DD.MM.YYYY HH24:MI:SS') BETWEEN
TO_DATE(TO_CHAR(TO_DATE('01.01.2010', 'DD.MM.YYYY') + (60692/86400), 'DD.MM.YYYY HH24:MI:SS'), 'DD.MM.YYYY HH24:MI:SS') AND
TO_DATE(TO_CHAR(TO_DATE('22.02.2010', 'DD.MM.YYYY') + (43200/86400), 'DD.MM.YYYY HH24:MI:SS'), 'DD.MM.YYYY HH24:MI:SS')

[kashperuk]

Цитата:

Сообщение от nix0root

Т.к. Axapta не умеет хранить в одном поле дату и время (например 11.11.2009 22:02:33), принято хранить эту информацию в двух отдельных полях (типы полей Date и Int). Это затрудняет поиск данных по периоду.

offtop:
Это справедливо только для более старых версий АХ, до появления типа utcDateTime

[nix0root]

Работаю на 4-ке, данного типа данных utcDateTime у меня нет

[Maximin]

Есть.
К примеру, таблица SysClientSessions.
Поле Login_date там именно такого типа, хотя нигде увидеть это из Аксапты невозможно - только из SQL Studio. Т.е. там не только дата входа хранится, но и время заодно, ибо SQL тип - DateTime.
Из-за этого, кстати, запросы типа select clientSessions where clientSessions.Login_date < systemdateget()) могут возвращать немного не то, что хотелось бы.
И в Global:: есть функция для работы с такими convertUTCDateToLocalDate, а вот обратной, кстати, нет, что приводит к проблемам с такими запросами.
Если интересно - можно еще посмотреть по ссылкам, где эта функция используется.
Но вот самому такое поле, думаю, заполнить не выйдет - это поле заполняется самим ядром.

[kashperuk]

Цитата:

Сообщение от nix0root

Работаю на 4-ке, данного типа данных utcDateTime у меня нет

Это потому что АХ 4 - старая версия
Данный тип был добавлен в АХ 2009

[nix0root]

В AX 2009 как я понимаю данный тип поля уже является стандартным? Т.е. его можно применить для редактирования т.п.
http://www.axaptapedia.com/UtcDateTime

[kashperuk]

Цитата:

Сообщение от nix0root

В AX 2009 как я понимаю данный тип поля уже является стандартным? Т.е. его можно применить для редактирования т.п.
http://www.axaptapedia.com/UtcDateTime

Да, тип стандартный. Более того, в большинстве таблиц, где присутствовали время и дата, была произведена замена на новый тип.

[nix0root]

Жаль что этот тип не откроют в полный доступ в 4-ке, на 2009 мы врятли будем переходить. Поэтому буду юзать прямые запросы к бд с TO_CHAR и TO_DATE

[Ivanhoe]

Цитата:

Сообщение от nix0root

Жаль что этот тип не откроют в полный доступ в 4-ке, на 2009 мы врятли будем переходить. Поэтому буду юзать прямые запросы к бд с TO_CHAR и TO_DATE

Если не секрет, почему врядли переходить будете?

[nix0root]

Во первых это дорого нам встанет.
Во вторых долго.
В третьих ловить ошибки потом в теч длительного времени , тк у нас много своих наработок.
Ну и самое главное у нас ORACLE )))) а на сколько я знаю 2009 уже никак не поддерживает ORA.

Собственно вот почему мы не будем переходить на 2009

[belugin]

2009 поддерживает ORACLE http://www.microsoft.com/dynamics/en...ents-2009.aspx

[S.Kuskov]

Цитата:

Сообщение от nix0root

буду юзать прямые запросы к бд

Извините конечно, но я так и непонял, что такого делает этот прямой запрос, что нельзя сделать средствами аксапты?
Вы же вот это хотели получить? Или я что-то не понимаю?

((T.Date > fromDate) || ((T.Date == fromDate) && (T.Time >= fromTime))) &&
((T.Date < toDate) || ((T.Date == toDate) && (T.Time <= toTime)))

У меня, напротив, встречный вопрос. Учитывая, что

Цитата:

Сообщение от kashperuk

в большинстве таблиц, где присутствовали время и дата, была произведена замена на новый тип.

Как теперь будут выглядеть запросы, в котроых ограничено должно быть только время, но не число?

[lev]

Цитата:

Сообщение от S.Kuskov

Извините конечно, но я так и непонял, что такого делает этот прямой запрос, что нельзя сделать средствами аксапты?
Вы же вот это хотели получить? Или я что-то не понимаю?

((T.Date > fromDate) || ((T.Date == fromDate) && (T.Time >= fromTime))) &&
((T.Date < toDate) || ((T.Date == toDate) && (T.Time <= toTime)))

Аксаптовскими средствами можно решить все, просто с большими трудозатратами
Например, есть таблицы:
Table1 с полями: FromDate, FromTime, ToDate, ToTime
Table2 с полями: FromDate, FromTime, ToDate, ToTime
известно значение Table2, нужно проверить есть ли пересекающиеся во времени строчки в Table1...

вот такой случай решается в аксапте геморойно

[nix0root]

Ну даже с учетом поддержки 2009-й OR-ы, стоимость и время все равно остаются критичными

[Ivanhoe]

Про переход и затраты понятно, но вот про возможности.. Пока из своего опыта 2009 намного стабильнее, полноценные 64 бита и т.п., в части функциональности много нового и интересного, в т.ч. локализаторы стараются.

В т.ч. дата и время не просто новый тип, он активно участвует в расчетах сроков поставки и проч., есть настройки часовых поясов пользователя.

[nix0root]

А с какой базой вы работаете если не секрет, и чем пользуетесь для отчетов?

[S.Kuskov]

Цитата:

Сообщение от lev

Аксаптовскими средствами можно решить все, просто с бОльшими трудозатратами

А неужели преоброзование типов работает быстрее пары лишних сравнений?

Цитата:

Сообщение от lev

Например, есть таблицы:
Table1 с полями: FromDate, FromTime, ToDate, ToTime
Table2 с полями: FromDate, FromTime, ToDate, ToTime
известно значение Table2, нужно проверить есть ли пересекающиеся во времени строчки в Table1...
вот такой случай решается в аксапте геморойно

Вообще эта задача ничуть не сложнее предыдущей. В том смысле, что для её решения нужно то же число сравнений.

((T1.fromDate < T2.toDate) || ((T1.fromDate == T2.toDate) && (T1.fromTime <= T2.toTime))) &&
((T1.toDate > T2.fromDate) || ((T1.toDate == T2.fromDate) && (T1.toTime >= T2.fromTime)))

P.S.: Накатал тут на коленке пару макросов для работы с датами и временем. Может кому пригодится.

#localmacro.lessOrEq
    /* (%1) - Date_1 */
    /* (%2) - Time_1 */
    /* (%3) - Date_2 */
    /* (%4) - Time_2 */
    ( ((%1) < (%3)) || ( ((%1) == (%3)) && ((%2) < (%4)) ) )
#endmacro

#localmacro.greatOrEq
    /*(%1) - Date_1 */
    /*(%2) - Time_1 */
    /*(%3) - Date_2 */
    /*(%4) - Time_2 */
    ( ((%1) > (%3)) || ( ((%1) == (%3)) && ((%2) > (%4)) ) )
#endmacro

#localmacro.dt
    /* (%1) - Date */
    /* (%2) - Time */
    %1, %2
#endmacro

#localmacro.between
    /* (%1) - DateFrom */
    /* (%2) - TimeFrom */
    /* (%3) - DateTo   */
    /* (%4) - TimeTo   */
    /* (%5) - Date     */
    /* (%6) - Time     */
    (#greatOrEq(#dt(%5, %6), #dt(%1, %2)) && #lessOrEq(#dt(%5, %6), #dt(%3, %4)))
#endmacro

#localmacro.cross
    /* (%1) - DateFrom_1 */
    /* (%2) - TimeFrom_1 */
    /* (%3) - DateTo_1   */
    /* (%4) - TimeTo_1   */
    /* (%5) - DateFrom_2 */
    /* (%6) - TimeFrom_2 */
    /* (%7) - DateTo_2   */
    /* (%8) - TimeTo_2   */
    (#lessOrEq(#dt(%1, %2), #dt(%7, %8)) && #greatOrEq(#dt(%3, %4), #dt(%5, %6)))
#endmacro

[lev]

Цитата:

Сообщение от S.Kuskov

А неужели преоброзование типов работает быстрее пары лишних сравнений?



Вообще эта задача ничуть не сложнее предыдущей. В том смысле, что для её решения нужно то же число сравнений.

((T1.fromDate < T2.toDate) || ((T1.fromDate == T2.toDate) && (T1.fromTime <= T2.toTime))) &&
((T1.toDate > T2.fromDate) || ((T1.toDate == T2.fromDate) && (T1.toTime >= T2.fromTime)))

Я не говорил что это не возможно, я сказал что это гемор
согласитесть, что вот так, было бы более прозрачно и понятно:

if (T1.FromDateTime <= T2.ToDateTime && T1.ToDateTime >= T2.FromDateTime)

[S.Kuskov]

Цитата:

Сообщение от lev

согласитесть, что вот так, было бы более прозрачно и понятно:

if (T1.FromDateTime <= T2.ToDateTime && T1.ToDateTime >= T2.FromDateTime)

Согласен. Про это нет и речи. Я, всего лишь, против прямого SQL там, где это не нужно

P.S.: А на мой вопрос (Дата и время в Axapta) есть у кого-нибудь ответ?

[kashperuk]

Цитата:

Сообщение от S.Kuskov

Согласен. Про это нет и речи. Я, всего лишь, против прямого SQL там, где это не нужно

P.S.: А на мой вопрос (Дата и время в Axapta) есть у кого-нибудь ответ?

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