Dynamics AX 2012: Перевести RecId в значение

Question

Я задал вопрос, аналогичный этому ранее (How to use RecId as a foreign key in a form), но хотел бы изучить его немного дальше в более сложном сценарии.

Сменные ключи работают отлично, когда у вас установлены индексы и разрешены дубликаты, но они не работают вообще с индексами с несколькими полями или если разрешение дубликатов установлено на «да».

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

Таблица А: Боб: 1, Салли: 1, Сь: 3 Таблицы B: 1: яблоки, 2: яблоки, 3: Апельсины "народ" привязанные к их любимым "продуктам" по пищевому RECID , указанную в таблице «Люди». Предположим, что в других столбцах есть дополнительные данные, которые делают эти записи уникальными, поэтому объединение «1: Яблоки» и «2: Яблоки» невозможно.

Кажется, должен быть способ написать метод отображения, чтобы перезаписать значение поля в сетке. Какие-либо предложения? Образец кода?

Благодаря

Answer 1

Во-первых, суррогатная замена FK делает (или, по крайней мере, должны) работать с составными ключами (например, {Имя, Фамилия}).

Во-вторых, вы указываете, что есть «дополнительные данные в других столбцах», которые делают эти записи уникальными ... Тогда почему эти столбцы не объединены с именем пищи, чтобы сформировать альтернативный ключ? Модель данных кажется неправильной (или, по крайней мере, некоторые метаданные не согласуются с условиями, указанными вами)

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

потока:

1) пользователь вводит значение (ы) в контрольной группе.

2) Выходы пользователя.

3) Используемые пользователем значения используются для поиска записи в связанной таблице.

4а) Если пользователь набран значение (ов) однозначно отображается в запись, что запись выбрана, иначе,

4b) Если пользователя набраны в значениях не являются единственно поиск представлен, чтобы позволить пользователь должен выбрать, какую запись они «означают». Обратите внимание, что поиск должен представлять коллекцию уникально идентифицируемых записей, чтобы пользователь знал, какую запись выбрать (если записи все выглядят одинаково в поиске, тогда они не поймут, что, черт возьми, они должны выбрать.)

5) После успешного разрешения введенных значений запись возвращается к исходной форме.

Учитывая этот поток, очевидно, что шаги 3-5 будут разбиты, если в таблице нет уникального индекса (ключа).(Как пользователь должен указывать уникальную ссылку на запись, если запись не имеет возможности однозначно идентифицироваться (если вы не хотите отображать RecId для пользователя) ???)

В исключительном случае что вы решили, что хотите по-прежнему использовать неидеальный индекс в качестве вашей группы полей замены, вы должны должен реализовать resolveReference и lookupReference, чтобы предоставить пользователю уникальное разрешение/опыт поиска (для обработки шагов 3-5 в приведенном выше потоке). Примечание. Общим примером использования этого является желание эффективно исключить неселективные поля из отображения в справочной группе и вместо этого позволить внешнему контексту или режиму неявно установить это значение. Например, если альтернативный ключ был {Size, Color}, можно было бы сделать «Цвет» глобальным контекстом формы - возможно, если пользователь выбрал цвет в верхней части формы - и только пользователь должен ввести Size в Эталонная группа ... Затем цвет может быть неявным образом добавлен обратно через переопределения resolveReference и lookupReference.