Field Fixed Relation в AX2012 R2

[trud]

Есть таблица - в ней 2 поля. Одно - enum (клиент или поставщик), другое код контрагента.
Стоит задача создать Relation так чтобы
если enum=клиент 'код контрагента' был клиентом
если enum=поставщик 'код контрагента' был поставщиком
На проекте принято все делать без ошибок Best Practice

С виду простая задача, однако решение в лоб упирается в ошибку Best Practice
"Only foreign key constraints are allowed on this table."

В интернете гуглил, по этой ошибке советуют создавать Relation вида foreign key, однако в relation такого вида не получится добавить условие Field Fixed

Вот сижу думаю что с этим можно сделать.
Самое удивительное что Microsoft для своих таблиц как-то умудрились отключить эту проверку, т.е. к примеру на InventPosting ошибка не возникает.
файл с таблицей прилагаю

[S.Kuskov]

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

[trud]

ну можно и просто 3 поля сделать - код клиента, код поставщика и тип.
Т.е. получается это такой мягкий намек - не использовать Relation вида Field fixed. все бы хорошо если бы они сами это повсеместно не использовали

[S.Kuskov]

Цитата:

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

ну можно и просто 3 поля сделать - код клиента, код поставщика и тип.

Сейчас подумалось, наверное при использовании наследования можно попробовать поле с контрагентом оставить в базовой таблице, а в дочерние таблицы вообще никакие поля не добавлять, а использовать их только для размещения на них Relation. Получится?

[trud]

Цитата:

Сообщение от S.Kuskov

Сейчас подумалось, наверное при использовании наследования можно попробовать поле с контрагентом оставить в базовой таблице, а в дочерние таблицы вообще никакие поля не добавлять, а использовать их только для размещения на них Relation. Получится?

нет, так нельзя, в Relation доступны только поля таблицы
да и непонятно, как работать с такими таблицами - все переводить на View? т.е. простейший while select не сделаешь

[belugin]

EnforceFKRelation устанавливается на таблицах, импортированных из 2009.

Мне кажется, с наследованием правильно сделать два наследника с двумя разными полями.

[S.Kuskov]

Цитата:

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

Мне кажется, с наследованием правильно сделать два наследника с двумя разными полями.

Ну вообще-то говоря да, в общем случае типы данных у этих полей ведь не обязаны совпадать.

Интересно а как теперь в стандарте реализуется механизм связи с использованием перечисления TableGroupAll?

[belugin]

Цитата:

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

Самое удивительное что Microsoft для своих таблиц как-то умудрились отключить эту проверку, т.е. к примеру на InventPosting ошибка не возникает.
файл с таблицей прилагаю

В макросе SysBPCheckIgnore нет InventPosting => где-то в логике бестпрактисов зашиты различия (может там RelationType какой установить надо). Можно поставить breakpoint в \Classes\SysBPCheck\addError и посмотреть в чем разница

[trud]

дебагинг выявил следующее
у таблицы есть невидимое св-во EnforceFKRelation(можно увидеть в xpo). если оно в 0, то данная ошибка не возникает. по умолчанию оно стоит в 1.
просто поменять его в xpo и загрузить таблицу с перезаписью не получится, оно игнорируется. если удалить таблицу и загрузить заново, то да, меняется.
К сожалению в моем варианте таблица много где используется, да и данные есть, т.е. вариант с удалением не проходит

[Logger]

Цитата:

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

дебагинг выявил следующее
у таблицы есть невидимое св-во EnforceFKRelation(можно увидеть в xpo). если оно в 0, то данная ошибка не возникает. по умолчанию оно стоит в 1.
просто поменять его в xpo и загрузить таблицу с перезаписью не получится, оно игнорируется. если удалить таблицу и загрузить заново, то да, меняется.
К сожалению в моем варианте таблица много где используется, да и данные есть, т.е. вариант с удалением не проходит

Интересно, что если создаешь табличку с нуля, то можно задублировать существующую табличку и это свойство скопируется в дубль. Возможно, кому то это будет проще.

[DSPIC]

Я очень надеюсь, что это недоразумение пофиксят\переделают в ближайших релизах. Я так и не нашел, как это зарезолвить по-человечески.
А пока я делаю так, :

1. Экспорт таблицы в XPO
2. Меняем блокнотом тип релейшена на PKFK
3. Импортируем обратно

[kashperuk]

Вряд ли как-то проверяет.
Возможно только такие банальности, как отсутствие дублей и т.п.

[lvan]

Я тоже с этой проблемой столкнулся, тоже докопался до этого EnforceFKRelation и забил в итоге
Так до сих пор и выдает эту ошибку BP при компиляции.

[belugin]

Есть макрос SysBPCheckIgnore, куда можно добавлять пути, которые не надо проверять на специфические ошибки

[Logger]

up-ну тему.

Поделитесь, спустя 7 лет.
Как вы решали проблему?

Отрубали EnforceFKRelation на таблице ?
Добавляли в макрос SysBPCheckIgnore ?
Проектировали по-другому структуру данных ? А как ?

P.S.
Как я понимаю, в 365-й аксапте все аналогично. Т.е. вопрос не устарел.

[Logger]

Цитата:

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

нет, так нельзя, в Relation доступны только поля таблицы
да и непонятно, как работать с такими таблицами - все переводить на View? т.е. простейший while select не сделаешь

Цитата:

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

Проектировали по-другому структуру данных ? А как ?

Попробую угадать как мыслили себе это проектировщики 2012-й / 365-й

Возьмем связку
InventTrans - SalesLine
или
InventTrans - SalesTable

Раньше (ax4 - ax2009) были связи :

Для SalesLine
\Data Dictionary\Tables\InventTrans\Relations\SalesOrderLine
условия:
InventTrans.InventTransId == SalesLine.InventTransId
при этом неявно подразумевалось Fixed условие
InventTrans.TransType == 0

Для SalesTable
\Data Dictionary\Tables\InventTrans\Relations\SalesOrderNum
условия:
InventTrans.TransType == 0
InventTrans.TransRefId == SalesTable.SalesId

Для фильтрации / связи всегда добавлялось условие по InventTrans.TransType


В 2012-й придумали промежуточную табличку со связью
InventTransOriginSalesLine

т.е. чтобы перейти от InventTransOrigin к SalesLine
идет джоин
InventTransOrigin - InventTransOriginSalesLine - SalesLine

В каждой связи нет Fixed условия по InventTransOrigin.ReferenceCategory (это аналог InventTrans.TransType).
Его заменила InventTransOriginSalesLine.
т.е. вместо фильтра по полю с типом записи мы просто джоиним нужную табличку сязей.

От InventTransOrigin к InventTransOriginSalesLine связь
InventTransOriginSalesLine.InventTransOrigin == InventTransOrigin.RecId

а от InventTransOriginSalesLine к SalesLine :
InventTransOriginSalesLine.SalesLineDataAreaId == SalesLine.dataAreaId
InventTransOriginSalesLine.SalesLineInventTransId == SalesLine.InventTransId



Ну в вашем случае, аналогия такая
atest -- InventTransOrigin
atest_cust -- InventTransOriginSalesLine
atest_vend -- InventTransOriginPurchLine
CustTable -- SalesLine
VendTable -- PurchLine

atest_cust новая табличка связей
поля
CustAccount
(если извращаться то refRecId ссылка на atest)

atest_Vend
поля
VendAccount
(если извращаться то refRecId ссылка на atest)

Ну и в случае фильтрации / связи вместо условия на atest.CustVendCode делаем джоин либо с atest_cust либо с atest_vend

А поле atest.CustVendCode как бы и не нужно.

Правда если табличка atest не предполагает других полей, то нужна ли она вообще ? Ее можно заменить union вьюхой от atest_cust и atest_vend


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

[Владимир Максимов]

Это не о том

Здесь речь идет о выборе в головной таблице того ТИПА объекта с которым в дальнейшем будет осуществляться работа. Не фиксация уже свершившегося факта как с InventTrans.TransType, а именно выбор. Каким путем дальше пойдет работа

Соответственно, на это завязано много "спец.эффектов". Когда переключая значение Base Enum автоматически переключаем и ряд функций, связанных с полем-ссылкой. Выпадающие списки, переход к основной таблице, контроль. И все это "автоматически". Без дополнительного кодирования

У меня подозрение, что это сознательная политика, которая предполагает, что от подобной практики надо отказываться, поскольку она явным образом противоречит созданной логики ссылочной целостности в dax2012 и старше.

Хотите работать с разными типами объектов - создавайте разные документы. Не надо смешивать в одном документе несколько типов объектов одновременно. Речь не идет о логах и проводках (итоговая "свалка"). Речь идет именно о самих исходных документах

Ну, условно говоря, если стоит вопрос, с поставщиком или с клиентом будем создавать заказ, то это надо делать 2 разных типа документов (набора таблиц): заказы с поставщиком и заказы с клиентом. Не надо пытаться "впихнуть" это все в один набор таблиц с фильтром по Base Enum


Если бы речь шла только и исключительно о ссылочной целостности, то это как раз показательный пример с InventTrans.Там же просто тупо выбросили TransType и все.

Не проводка выбирает с кем будет работать, а проводку создают из заранее известного документа. Поэтому TransType в ней выполнял не управляющую, а информационную (справочную) функцию. Избыточно с точки зрения нормализации (лишнее поле). Вот его и выбросили. А что связи искать потребуется больше времени, так это не аргумент

[Logger]

Ну а как бы вы решили проблему описанную в заголовке темы ?
По другому спроектировали бы данные ?
Обошли бы проверку? Как ?

[Владимир Максимов]

Если формально, то либо делать отдельные поля на каждую сущность, либо отдельные наборы таблиц/форм/меню.

Если сущности для выбора можно как-то объединить (например, клиента и поставщика можно "объединить" через ГАК), то сделать нечто вроде почтовых адресов. Список контрагентов, где идентификатор - это ссылка на ГАК, а клиент/поставщик - это уже реквизит выбранной записи

Данный функционал явно противоречит новой идеологии. Нарушение принципов нормализации. Не должно быть поля, которое может содержать ссылки на разные таблицы. Думаю, будут по тихому "под коврик заметать"

Обход проверки - это из разряда "хакерских трюков". Раз разработчики Axapta посчитали данный функционал не желательным, то пытаться его поддерживать своими силами, ну, можно, конечно, но за дополнительные деньги