![]() |
#1 |
Участник
|
Как сделать с суррогатными ключами
нужно в таблицу добавить два новых поля:
1) Тип 2) Подтип причем лукап подтипов должен быть отфильтрован на основе выбранного типа. до ax2012 было просто релейшенами сделать, и без всякого кода таких два поля с лукапами можно было сделать а в Ax2012 сделали replacement key всякие и не получается уже так сделать. (в релейшн типа foreign key нельзя добавить фильтр) Как быть? |
|
![]() |
#2 |
Участник
|
походу без кода никак не сделать
перекрывать надо методы resolveReference и lookupReference |
|
![]() |
#3 |
Участник
|
А не использовать суррогатный ключ нельзя?
__________________
Ivanhoe as is.. |
|
![]() |
#4 |
Участник
|
|
|
![]() |
#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). |
![]() |
#6 |
Участник
|
С обычным Relation не будет работать Reference Data Sources.
Сейчас проверил сложный первичный ключ тоже не получится сделать. Первичный ключ должен содержать только одно поле ( |
|
![]() |
#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). |
![]() |
#8 |
Участник
|
можно, но я так понял, что в AX2012 так принято
хочу делать так, как принято вот тут описан сценарий похожий, но отличие в том, что фильтр у них не в поле primary таблицы, а отдельный контрол на форме http://www.microsoft.com/en-us/downl....aspx?id=35369 там предлагают код писать тоже Последний раз редактировалось Vasiliy Petrovich; 16.10.2015 в 19:30. |
|
![]() |
#9 |
Участник
|
|
|
![]() |
#10 |
Участник
|
Без необходимости не надо так делать. На практике в 2012 это не принято. Куча лишних проблем с отладкой, начальными данными, bi и т.п.
__________________
Ivanhoe as is.. |
|
|
За это сообщение автора поблагодарили: trud (1). |