Почему Dynalink не создаётся?

[lvan]

Какая-то мистика, на таблице есть два Relation один к одной таблице, другой к другой
С виду все одинаково, но dynalink только с первым релейшеном работает.
где посмотреть код, который определяет, создавать этот Dynalink или нет?

[Logger]

По идее со вторым тоже должно работать.
Выбирает всегда ядро. Причем в ситуации, когда есть неоднозначность, берется relation стоящий выше в AOT, поэтому играя названием relation-а можно попробовать управлять какой из них ядро будет рассматривать в первую очередь.

Но если хотите гарантированного результата - сделайте дайналинк руками. Пример - датасорсы формы Address.

[Logger]

про 2012-ю
см. еще
Dynalink в AX2012

[lvan]

Похоже на то
Щас читаю Release Notes к R3, тут про то же написано похоже:

Цитата:

Invalid information might be displayed in query results
When there are multiple relations between two tables in a Microsoft Dynamics AX database, and you run a query that includes relations that are automatically detected, the query results might contain invalid information. The system might detect relations in a sequence that is different from what is intended in the query.
Queries where relations are automatically detected include the following examples:
1. Auto join in query
2. Queries created by using the sys query form
3. Delete actions where a relation path is not specified
4. Dyna-linked data sources
To work around this issue, open the AOT and rename the relations so that they appear in the desired alphabetic order. For example, if you want a query to return results from the InventTable that are associated with a vendor and not the AlcoholManufacturerer_RU relation for the vendor, change the AlcoholManufacturerer_RU relation name to ZAlcoholManufacturerer_RU.

[pedrozzz]

Цитата:

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

change the AlcoholManufacturerer_RU relation name to ZAlcoholManufacturerer_RU

ага, шикарный воркэраунд, потом еще появятся ZZTableName, YTableName и т.д. и т.п. и прыгай по АОТ в поисках нужного релейшена, чтобы его состав посмотреть. А учитывая, что теперь релейшены на EDT не комильфо, а должны быть вынесены на таблицы, то в сколь-нибудь крупной таблице поиск нужного с таким подходом может стать той еще задачей. Я даже не говорю о рисках, когда кто-нибудь, не зная таких тонкостей, в процессе доработок добавит новый релейшен ATableName и сам того не подозревая к чертям сломает всю бизнесс логику в местах ему неизвестных. Тогда бы уж добавили на релейшен еще одно свойство Order, где можно было бы указать его приоритет. Так себе решение, но хоть как-то риски снижает и с кривыми наименованиями не придется извращаться.