Почему свойство запроса `FetchMode` удаляет поля из родительского источника данных?

Question

При открытии запроса SalesTableListPage из AOT, вы можете выбрать поле MatchingAgreement (отображается как "Идентификатор записи заголовка соглашения (Record-ID)") в поле поиска. То же самое невозможно для запроса SalesUpdateполе MatchingAgreement и несколько других (которые, кажется, связаны с полями отношения, где отношение построено с RecId) не показаны в поиске.

После некоторых исследований я обнаружил, что причина, по-видимому, заключается в FetchMode собственность на объединенный SalesLine источник данных. Если это 1:n, поля не отображаются в поиске. Если это 1:1, поля отображаются в поиске.

Я не проверял это с другими таблицами, но подозреваю, что такое же поведение. Я также протестировал это только с AX 2012 R2 и R3, но я подозреваю, что такое же поведение в других версиях 2012 года.

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

Answer 1

TL; поиск полей DR в диалоговом окне запроса не всегда работает для полей отношения, которые определяют отношения к таблицам, где AutoIdentification свойство группы полей AutoPopulate установлен в No, Один из случаев, когда они не работают, это когда источник данных объединяется с FetchMode 1: п.

Хотя в ответе Алекса К есть несколько интересных предложений, в моем случае виновником является AutoPopulate собственность на AutoIdentification группа полей таблицы AgreementHeader, В слое sys это свойство имеет значение No и группа содержит поля, которые отображаются в поиске диалогового поля запроса, если отношение в запросе равно 1:1. Если это свойство переключено на Yes поиск покажет поле Agreement header record ID (Record-ID) (и только это поле, независимо от того, как FetchMode отношения запроса определяется).

В основном, AX будет использовать информацию из AutoIdentification группа полей для определения информации, отображаемой в графическом интерфейсе в случае суррогатных ключевых ссылок / отношений. Если AutoPopulate свойство группы полей Yes, AX будет использовать альтернативный ключ таблицы для определения полей, которые будут использоваться. Если альтернативного ключа не существует (как в случае с таблицей AgreementHeader), AX использует поле отношения. Если AutoPopulate является No используются поля, определенные в группе. Но, как описано, эта опция не работает, если отношение в запросе не равно 1:1 (и, к сожалению, ни одна из альтернативных опций, таких как использование поля отношения, кажется, не реализована).

FetchMode    AutoPopulate     Lookup
1:1          Yes              AlternateKey (or Relation) fields
1:1          No               AutoIdentification fields
1:n          Yes              AlternateKey (or Relation) fields
1:n          No               Nothing

Обновление: я столкнулся с этой проблемой снова, но с полем SalesTaker этот раз. Оказывается, что AutoPopulate свойство является лишь частью истории, потому что оно не решает проблему, когда установлено Yes на столе HcmWorker, Эта таблица (в отличие от таблицы AgreementHeader) также имеет свойство ReplacementKey набор, который AX использует для заполнения AutoIdentification полевая группа. Только после того как я удалил ReplacementKey в поле больше нет полей AutoIdentification и поиск теперь показывал "Sales takeer (Record ID)". Итак, суть в том, что AutoIdentification группа полей не должна содержать никаких полей.

Answer 2

Если dynamic свойство обоих полей запроса установлено в yesтогда я подозреваю, что это как-то связано со свойствами одного из этих отношений:

\Data Dictionary\Tables\SalesTable\Relations\Agreement

\Data Dictionary\Tables\SalesLine\Relations\SalesTable

Возможно, попробуйте настроить их, обновить кэш (изменения AOT, которые нужно забрать), очистить данные об использовании (упакованные запросы могут вызвать проблемы) и обновить XRef (расширенные запросы используют XRef, поэтому могут не требоваться для стандартных функций запросов)