глючный UTCdatetime или руки кривые?

[IKA]

В фильтре на форме с гридом (инвойсы) задаю фильтр CreatedDateTime = '17.08.2010'. Нажимаю OK. Все записи фильтруются так, что только созданные за '17.08.2010' остаются в гриде. Все ок. Открываю Фильтр снова, там вместо моего '17.08.2010' уже значится "17/08/2010 00:00:00". Ничего не меняю, нажимаю ОК, все записи из грида пропадают (не смотря на то, что я ничего не поменяю).


Такой же баг вижу в коде. Пользователь наклыдвает критерии на запрос в диалоге класса Runbase, выбирает поле CreatedDateTime и указывает дату '17.08.2010'. Я беру этот запрос в коде и считаю количество записей и вижу, что возвращается 0, ищу причину и виже что '17.08.2010' в запросе преобразовано в = "17/08/2010 00:00:00".

как корректно ввести дату как критерий для поля типа UTCDatetime запроса?

AX 2009 SP1 RU-3

[ansoft]

Прикольно...
Думается критерий должен быть: "17.08.2010 00:00:00".."17.08.2010 23:59:59"

[gl00mie]

Цитата:

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

В фильтре на форме с гридом (инвойсы) задаю фильтр CreatedDateTime = '17.08.2010'. Нажимаю OK. Все записи фильтруются так, что только созданные за '17.08.2010' остаются в гриде. Все ок. Открываю Фильтр снова, там вместо моего '17.08.2010' уже значится "17/08/2010 00:00:00".

Это глюк ядра Аксапты до RU4 включительно - она зачем-то дату вот в такую временную метку в range'ах переделывает. В RU5 это уже исправили - там ядро переделывает дату в диапазон с полуночи до 23:59:59

[IKA]

Цитата:

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

Это глюк ядра Аксапты до RU4 включительно - она зачем-то дату вот в такую временную метку в range'ах переделывает. В RU5 это уже исправили - там ядро переделывает дату в диапазон с полуночи до 23:59:59

Красота..... вот сейчас пользователи обрадуются, когда скажу, как им критерии забивать надо будет.
Спасибо большое за ответ gl00mie!

[IKA]

Есть кой-нить HF который можно на RU3 накатить, чтобы избавиться от этой проблемы?

[gl00mie]

А чем вам RU5 не подходит? Поставьте из него только обновленное ядро - там еще куча других косяков исправлена.

[IKA]

Вы пробовали усталавливать только ядро от него, действительно работает?
МС открещивается на всякий случай:
"The rollup package contains both a cumulative kernel update and a cumulative application update. Although there is no dependency between these two updates, we recommend that you install both of the updates together. The rollup will be installed on the SYP layer and the GLP layer."

[gl00mie]

MS, судя по цитате, не открещивается, а напрямую заявляет, что никакой зависимости между ядром и приложением нет. Собственно, со времен трешки в установке нового ядра (если не считать перехода на KRx) ничего "такого" не было и нет. Ставить ядро RU5 (5.0.1500.2985) именно на приложение RU3 я не пробовал, но ставил на приложение RU4, и никаких новых проблем при этом не вылезло.

[IKA]

спасибо

[Consciousness]

Всем доброго времени суток!
Подниму старую тему все же.
Стоит Ax2009 Ru5

Проблема с типом UTCDatetime все же не решилась! Есть форма, на форме имеются датасорсы с полями типа UTCDatetime, так же на форме считается и выводится кол-во отфильтрованных записей. Так вот, если наложить фильтр на любое из полей типа UTCDateTime - счетчик не срабатывает и показывает 0. (самый простой пример - сделать фильтр по выделению на поле CreatedDateTime, как минимум одна строка найдется, а счетчик показывает 0)
Копаюсь глубже, смотрю в sysQuery какой запрос у квери подсчета кол-ва уже ушедший на SQL - оказывается, что при копировании квери значение range на поле типа UTCDatetime копируется не верно - не учитывает временную зону! Т.е при наложиении фильтр наклыдвается по гринвичу - минус часовой пояс, а копирует фильтр - часовой пояс не отнимает и вместо времени 7-45, к примеру, копирует 10-45.
Проблему локально решить можно, но хотелось бы более глобального решения, особенно если учесть множество временных форматов и многоязычную компанию! Кто сталкивался с подобным, подскажите, пожалуйста!

[kashperuk]

Цитата:

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

Всем доброго времени суток!
Подниму старую тему все же.
Стоит Ax2009 Ru5

Проблема с типом UTCDatetime все же не решилась! Есть форма, на форме имеются датасорсы с полями типа UTCDatetime, так же на форме считается и выводится кол-во отфильтрованных записей. Так вот, если наложить фильтр на любое из полей типа UTCDateTime - счетчик не срабатывает и показывает 0. (самый простой пример - сделать фильтр по выделению на поле CreatedDateTime, как минимум одна строка найдется, а счетчик показывает 0)
Копаюсь глубже, смотрю в sysQuery какой запрос у квери подсчета кол-ва уже ушедший на SQL - оказывается, что при копировании квери значение range на поле типа UTCDatetime копируется не верно - не учитывает временную зону! Т.е при наложиении фильтр наклыдвается по гринвичу - минус часовой пояс, а копирует фильтр - часовой пояс не отнимает и вместо времени 7-45, к примеру, копирует 10-45.
Проблему локально решить можно, но хотелось бы более глобального решения, особенно если учесть множество временных форматов и многоязычную компанию! Кто сталкивался с подобным, подскажите, пожалуйста!

А не могли бы Вы прикрепить сюда или выслать мне лично рабочий xpo, демонстрирующий это поведение, а по возможности - еще и код из SysQuery, где происходит ошибка?

[Consciousness]

Да, прикрепила проект
В инфологе запрос с датасорса формы и запрос скопированный для подсчета количества строк.
Спасибо )

[BOAL]

Не буду плодить новой темы, хотя и достойно базы знаний.

AX2009 ru6

EDT CreatedDateTime и любые другие станлратные ЕДТ или свои новый таких типов примененный в дисплей методах - НЕ РАБОТАЮТ

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

Кончилось тем, что преобразовали поле к дате и вернули только ее с ЕДТ даты.

Выглядит так: на закладке разное поле бесконечной длины, пустое.
Сделать свой ЕДТ с ДисплейЛен 30 можно, все становится коротенько, но поле по прежнему пустое.
Из чего делается вывод, что тип ДатаВремя не применим в вычислимых методах..... вот тебе и мега фича.
Если же добавлять поле таблицы, а не метод, все рисуется ок.

[Ivanhoe]

Например, такой код работает верно:

display UTCDateTime time()
{
    return DateTimeUtil::getSystemDateTime();
}

DAX2009 SP1 RU6.

[BOAL]

Да, этот Edt работает, но у него метка не та.
А вот стандартные другие ЕДТ?
Я пробовал на ActivationDateTime он sys
и на своем, отнаследованном от этого, от КреатедДайтТайм или без наследования.

А вот UTCDateTime в качестве родителя у ЕДТ не ставится, и сотв получить счастье не выходит.

Остается вариант все клнтрольки делать от UTCDateTime и называть их метками на самой форме. Но это изврат и баг.

Так что, все еще прошу подтвердить поведение прочих не UTCDateTime ЕДТ в дисплей филдах на закладке формы.

ЗЫ. А вообще не забавно, что на стартапе проекта с переходом на ах2009 время стало уходить в утиль (неоплачиваемое и овертаймовое) оч сильно - граблями устелен этот путь, там где их не было отродясь (настроил и полетел) - накидали пачками грабельки, усердно, добротно, что все плюсы новой системы (кроме маркетинговых и обязалово-сейлозых) меркнут.
Из недавнего еще в ЖГК ОС\Строки\Групповые операции - кривые диалоговый формы с dialogField = new DialogField() вместо dialogField = dialog.addFieldValue

[DSPIC]

Цитата:

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

Не буду плодить новой темы, хотя и достойно базы знаний.

AX2009 ru6

EDT CreatedDateTime и любые другие станлратные ЕДТ или свои новый таких типов примененный в дисплей методах - НЕ РАБОТАЮТ

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

Кончилось тем, что преобразовали поле к дате и вернули только ее с ЕДТ даты.

Выглядит так: на закладке разное поле бесконечной длины, пустое.
Сделать свой ЕДТ с ДисплейЛен 30 можно, все становится коротенько, но поле по прежнему пустое.
Из чего делается вывод, что тип ДатаВремя не применим в вычислимых методах..... вот тебе и мега фича.
Если же добавлять поле таблицы, а не метод, все рисуется ок.

Не могли бы вы по-русски четко написать, что именно не работает, желательно знаки препинания расставить. Что-то я 3 раза прочитал, так и не понял в чем проблема.

[gl00mie]

Цитата:

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

А вот UTCDateTime в качестве родителя у ЕДТ не ставится, и сотв получить счастье не выходит.

По-моему, UtcDateTime - это базовый тип, как Date или Int, а не расширенный, поэтому от него и нельзя ничего "наследовать".

Цитата:

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

А вообще не забавно, что на стартапе проекта с переходом на ах2009 время стало уходить в утиль (неоплачиваемое и овертаймовое) оч сильно - граблями устелен этот путь, там где их не было отродясь (настроил и полетел)

Ууу, то ли еще будет!.. Но вы же на RU7 переходите? Тогда от кучи граблей вы уже избавлены - что в приложении, что в ядре. А на счет настроил и полетел - это когда такое было? Я, наверно, что-то пропустил

[sukhanchik]

Цитата:

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

Но вы же на RU7 переходите? Тогда от кучи граблей вы уже избавлены - что в приложении, что в ядре.

Ээээ этот вопрос был задан в тоне иронии или на полном серьезе? В плане "многих фиксов в RU7" ?
Т.е. я конечно понимаю, что каждый RUx содержит в себе пачку исправлений и улучшений, но это еще не означает что "чем дальше, тем стабильнее". По моему - так вообще в RU3 не было много такой "мелочевки", типа dialogField = new DialogField (вроде как - точно уже не скажу). Т.е. какие-то грабли явно прибавились после.

Тот же RU7 конечно может и хорош - но зарплата к нему вот только только вышла - соответственно - при использовании (хотя бы частично) функционала из зарплаты - ставить RU7 до выхода зарплаты бессмысленно (при этом МС не утруждает себя хранить версии зарплаты на каждый RUx и норовит обновить слой после выпуска фиксов в XPO. Т.е. получается, что без залитого в usr-слой нужного XPO-шника приложение с зарплатным слоем не компилируется).

[AndyD]

Цитата:

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

Да, этот Edt работает, но у него метка не та.
А вот стандартные другие ЕДТ?
Я пробовал на ActivationDateTime он sys
и на своем, отнаследованном от этого, от КреатедДайтТайм или без наследования.

А вот UTCDateTime в качестве родителя у ЕДТ не ставится, и сотв получить счастье не выходит.

Остается вариант все клнтрольки делать от UTCDateTime и называть их метками на самой форме. Но это изврат и баг.

Так что, все еще прошу подтвердить поведение прочих не UTCDateTime ЕДТ в дисплей филдах на закладке формы.

А вы драг&энд&дропом контролы на форме получаете?
В морфиксе есть глюк. Если перетаскивать на форму методы с EDT типа UTCDateTime, то он создает контролы StringEdit, которые неправильно отображают эти методы.

Просто, создавайте контролы на форме через Создать Control/UTCDateTimeEdit, а потом указывайте в нем датаметод и датасорс, если надо.
Либо, указывайте изначально в методе возвращаемый тип UTCDateTime, создавайте метод драг&энд&дропом, а после этого меняйте возвращаемый тип в методе на нужный вам.

Извращение, конечно, но пока не исправят - что делать?

[BOAL]

У нас эта форма появилась переносом и заменой из-за пропажи полей CreatedDate на таблицах.
Теперь ясно, как делать такие дисплей поля.

Спасибо!

gl00mie
на РУ7 переход не планировали.
От чего это спасет? Чтоб понять стоил ли связываться.
Что лечит ядро, а что прил., то есть может просто накатить АОС и клиент и оставить прил. от Ру6?