AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Программирование
DAX
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 24.03.2008, 18:03   #1  
IvanOFF is offline
IvanOFF
MCTS
MCBMSS
 
65 / 87 (3) ++++
Регистрация: 22.09.2005
Адрес: Москва
Оповещения. Переход к источнику оповещения.
Здравствуйте!
Заметил такую особенность в работе стандартного механизма оповещения в AX 4.0.
Например, если настроить оповещение на изменение поля таблицы "Договоры" (RContractTable - неважно, у клиентов или поставщиков), то позже из этого оповещения (форма "Просмотр оповещений" - EventAlertInbox) нельзя перейти к той записи, у которой было изменено поле. Открывается форма договоров, выделяется поле грида, в котором было изменение, но выбрана первая запись, а не та, на которой было сгенерировано оповещение. На других формах функционал отрабатывает корректно - переходит к нужной записи.

После анализа кода, выяснилось то отличие таблицы договоров от других таблиц, которое приводит к такому поведению. Это - составной первичный ключ. В классе EventContextInformation за поиск записи на форме отвечает метод find(), в самом начале которого идет проверка - canUseFindRecord(), который в случае с RContractTable возвращает false. Этот false, в свою очередь, определяется методом canUseLookup() того же класса, который также возвращает false из-за вот этой проверки:
X++:
di = this.getPrimaryIndex();
if (! di || di.numberOfFields() != 1)
    return false;
которая из-за составного первичного ключа возвращает false. Если в отладчике вручную заставить вернуть метод canUseLookup() значение true, то запись корректно находится.
Может, у кого-нибудь есть идеи, зачем так сделано? Зачем таблицы с составным первичным ключом обрабатываются иначе, чем те, у которых первичный ключ содержит одно поле. Может, в этом и есть какой-то смысл, но функционал при этом работает не корректно.
Исправить-то можно, конечно, но хотелось бы разобраться.
Старый 25.03.2008, 09:24   #2  
AndyD is offline
AndyD
Участник
КОРУС Консалтинг
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
2,560 / 2476 (88) +++++++++
Регистрация: 20.08.2005
Что бы долго не ждать, когда отфетчится нужная запись

Когда создается форма, то запись в ней позиционируется с помощью механизма JumpRef (с помощью методов LookupField(), LookupValue() класса Args). При использовании на таблице составного ключа, ищется по первому полю первого уникального индекса. После открытия формы происходит дополнительное позиционирование с помощью метода findRecord() нужного датасорса.
Если переход был выполнен по составному ключу, то после открытия формы запись будет отпозиционирована на первом поле составного ключа (для RContractTable на значении поля RContractPartnerType) и, если закомментировать соответствующий код в методе canUseFindRecord(), будут фетчиться записи на клиента, пока будет получена нужная, что в общем случае может занять много времени.
__________________
Axapta v.3.0 sp5 kr2
За это сообщение автора поблагодарили: IvanOFF (1).
Старый 25.03.2008, 12:30   #3  
IvanOFF is offline
IvanOFF
MCTS
MCBMSS
 
65 / 87 (3) ++++
Регистрация: 22.09.2005
Адрес: Москва
Цитата:
Сообщение от AndyD Посмотреть сообщение
Что бы долго не ждать, когда отфетчится нужная запись

Когда создается форма, то запись в ней позиционируется с помощью механизма JumpRef (с помощью методов LookupField(), LookupValue() класса Args). При использовании на таблице составного ключа, ищется по первому полю первого уникального индекса. После открытия формы происходит дополнительное позиционирование с помощью метода findRecord() нужного датасорса.
Если переход был выполнен по составному ключу, то после открытия формы запись будет отпозиционирована на первом поле составного ключа (для RContractTable на значении поля RContractPartnerType) и, если закомментировать соответствующий код в методе canUseFindRecord(), будут фетчиться записи на клиента, пока будет получена нужная, что в общем случае может занять много времени.
Понятно. Спасибо!
То есть, получается, что лучше быстро, чем правильно Ведь, согласитесь, искать запись, откуда было сгенерировано оповещение, вручную вряд ли окажется быстрее, чем подождать, пока "отфетчится" нужная запись по составному ключу.
Старый 27.03.2009, 16:07   #4  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,143 / 2155 (80) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
Подниму тему. Кто-нибудь решал такую задачу? Попробовал закоментить анализ количества полей в индексе и вообще установку поля лукапа в args - запись все равно находится верно.

Кроме производительности, есть еще узкие места такой модификации?
__________________
Ivanhoe as is..
Теги
оповещения, ax4.0

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Оповещения (alerts) в DAX 4.0 sparur DAX: Программирование 55 31.05.2017 16:14
Не работают оповещения AlexeyBP DAX: Функционал 4 21.08.2007 11:32
ALEG: Фишка недели: Бизнес Оповещения или сказ о том, как ИТ менеджер улучшал продуктивность бизнеса Blog bot DAX Blogs 10 16.01.2007 14:06
Запрос по добавленному пользователем источнику данных ZSV DAX: Программирование 0 18.03.2005 17:33
Переход на правильную запись при Переходе к основной таблице. - 2 Anais DAX: Программирование 2 01.11.2004 17:14
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 20:59.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.