16.10.2015, 04:23 | #1 |
Участник
|
Как сделать с суррогатными ключами
нужно в таблицу добавить два новых поля:
1) Тип 2) Подтип причем лукап подтипов должен быть отфильтрован на основе выбранного типа. до ax2012 было просто релейшенами сделать, и без всякого кода таких два поля с лукапами можно было сделать а в Ax2012 сделали replacement key всякие и не получается уже так сделать. (в релейшн типа foreign key нельзя добавить фильтр) Как быть? |
|
16.10.2015, 09:19 | #2 |
Участник
|
походу без кода никак не сделать
перекрывать надо методы resolveReference и lookupReference |
|
16.10.2015, 09:56 | #3 |
Участник
|
А не использовать суррогатный ключ нельзя?
__________________
Ivanhoe as is.. |
|
16.10.2015, 10:47 | #4 |
Участник
|
|
|
16.10.2015, 11:10 | #5 |
Участник
|
Не делайте Relation типа Foreign Key. Сделайте обычный Relation типа Normal. В чем проблема-то? Их отличие только в значении определенного флага на этом самом Relation. С точки зрения собственно работы никаких отличий нет. Это исключительно "дизайнерская фича" для автоматического формирования ряда настроек при создании этого самого Relation
Если Вас смущает сообщение Best Practices, то для отдельно взятой таблицы проверку Relation на Foreign Key можно отключить через модификацию флага в заголовке (правда, только через XPO) Подробно описано здесь https://erpcoder.wordpress.com/2014/...on-this-table/ А если вкратце, то отключить проверку Relation на Foreign Key для конкретной таблицы можно так:
__________________
- Может, я как-то неправильно живу?! - Отчего же? Правильно. Только зря... |
|
|
За это сообщение автора поблагодарили: Logger (1). |
16.10.2015, 11:40 | #6 |
Участник
|
С обычным Relation не будет работать Reference Data Sources.
Сейчас проверил сложный первичный ключ тоже не получится сделать. Первичный ключ должен содержать только одно поле ( |
|
16.10.2015, 14:02 | #7 |
Administrator
|
Цитата:
Во-первых, Relation типа ForeignKey дает возможность установить на Relation-е свойство CreateNavigatePropertyMethods и впоследствии пользоваться не только теми методами, которые находятся в узле Methods, но и динамически создаваемыми методами перехода от одной таблицы к другой. Во-вторых, в форме расширенного фильтра есть возможность выбирать из списка полей не только поля выбранной таблицы и ее родителей, а еще и связанных по ForeignKey таблиц (см таблицу VendTable и релейшн MainContactWorker на таблицу HcmWorker; в форме - это поле Ответственный). И этот выбор зависит от значения метода sysDictField.isSurrogateForeignKey(). Сейчас, если создать Relation типа Обычный и добавить одну связку - то независимо от того - взведен флаг с ForeignKey у релейшна или нет, и метод CreateNavigatePropertyMethods на релейшне доступен и метод sysDictField.isSurrogateForeignKey() возвращает значение True. Все эти прелести пропадают при добавлениии в релейшн второго поля-связки. Соответственно, с учетом того, что система хранит информацию о том, как был создан Relation - через ForeignKey или через Nornal - никто не застрахован от того, что метод sysDictField.isSurrogateForeignKey() будет смотреть на этот флаг (а это ядро между тем), а также пропадет свойство CreateNavigatePropertyMethods у релейшна, у которого "нет полномочий его менять. Но пока оно работает... хорошо
__________________
Возможно сделать все. Вопрос времени |
|
|
За это сообщение автора поблагодарили: EVGL (1), Владимир Максимов (1), Cardagant (1). |
16.10.2015, 19:28 | #8 |
Участник
|
можно, но я так понял, что в AX2012 так принято
хочу делать так, как принято вот тут описан сценарий похожий, но отличие в том, что фильтр у них не в поле primary таблицы, а отдельный контрол на форме http://www.microsoft.com/en-us/downl....aspx?id=35369 там предлагают код писать тоже Последний раз редактировалось Vasiliy Petrovich; 16.10.2015 в 19:30. |
|
16.10.2015, 19:33 | #9 |
Участник
|
|
|
16.10.2015, 20:46 | #10 |
Участник
|
Без необходимости не надо так делать. На практике в 2012 это не принято. Куча лишних проблем с отладкой, начальными данными, bi и т.п.
__________________
Ivanhoe as is.. |
|
|
За это сообщение автора поблагодарили: trud (1). |