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. все бы хорошо если бы они сами это повсеместно не использовали

[belugin]

Цитата:

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

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

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

[S.Kuskov]

Цитата:

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

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

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

[trud]

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

[trud]

Цитата:

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

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

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

[belugin]

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

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

[DSPIC]

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

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

[S.Kuskov]

Цитата:

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

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

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

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

[trud]

Цитата:

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

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

Думаю все как и было. просто Microsoft умеет сбрасывать EnforceFKRelation у таблиц

[kashperuk]

Цитата:

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

Думаю все как и было. просто Microsoft умеет сбрасывать EnforceFKRelation у таблиц

Ну, это сильно сказано.
Думаю все зависит от наличия или отсутствия заполненного поля LegacyID

[MikeR]

Цитата:

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

Думаю все зависит от наличия или отсутствия заполненного поля LegacyID

Стало интересно, а система как-нибудь проверяет корректность введенных в это поле данных при импорте или можно любое значение ставить?

 LegacyId            #1517

[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]

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