Цитата:
Сообщение от
EVGL
Раньше Best Practices были слегка параноидальными и ругались на отсутствие ссылки на самого себя.
Думаю что не только по этой причине делают в Relation связь таблицы самой на себя.
Тут все хитрее. Дело в том что движок Аксапты может определять связь между таблицами как через связи определенные на EDT, так и через связи определенные на уровне таблиц, причем у последних приоритет выше.
У меня был реальный пример. Есть таблица SalesTable - у неё не определена связь на саму себя через salesId. Если на форме SalesTable нажать Запросы - Итоги - то откроется форма подсчета итогов и сработает Dynalink - будет связь по SalesId. Спрашивается, откуда она взялась ? Судя по всему из расширенного типа данных которые прописан в SalesTable.salesId
Далее, делаем какую-нить кастомизацию - определяем на SalesTable составной relation по 3 новым полям.
SalesTable.CUSTOM_DataAreaId == SalesTable.DataAreaID
SalesTable.CUSTOM_SalesId == SalesTable.SalesId
SalesTable.CUSTOM_SourceType == 0 // поле с типом Енум - неважно какое.
(Это мы цепочки писали - задавали таким образом свои связи между заказами в разных компаниях)
И после этого ломается форма Запросы - Итоги !!! Везде.
Даже на тех заказах, на которых поля
SalesTable.CUSTOM_DataAreaId
SalesTable.CUSTOM_SalesId
SalesTable.CUSTOM_SourceType
пустые !
Оказывается система подхватывал Dynalink уже по новой связке ! Хотя по идее не должна была. Так как значения в полях не подходили. Она взяла кусок Relation-а и стала по нему делать Dynalink !
Т.е. получается что ядро Аксапты видит, что в relation-х таблицы есть связка по SalesId - после этого забивает на связки в расширенных типах которые прописаны в полях. Выкусывает из составного relation по 3-м полям связку по одному полю SalesId.CUSTOM_SalesId == SalesTable.SalesId и использует его в качестве Dynalink при вызове Запросы - Итоги
Пипец.
Но стоило мне определить на таблице отдельный Relation с тавтологической связкой
SalesTable.SalesId == SalesTable.SalesId
как все чудесным образом вылечилось.