AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Программирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 03.06.2013, 08:29   #1  
trud is offline
trud
Участник
Лучший по профессии 2017
 
947 / 1297 (45) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Field Fixed Relation в AX2012 R2
Есть таблица - в ней 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 ошибка не возникает.
файл с таблицей прилагаю
Вложения
Тип файла: xpo Table_atest.xpo (3.5 Кб, 441 просмотров)
За это сообщение автора поблагодарили: sukhanchik (2), Logger (5).
Старый 03.06.2013, 08:46   #2  
S.Kuskov is offline
S.Kuskov
Участник
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
3,292 / 1625 (61) ++++++++
Регистрация: 28.04.2007
Адрес: Калуга
Видимо, по новой идеологии AX2012 в таких случаях нужно делать двух наследников от базовой таблицы. В одной таблице-наследнике делать поле со связью на клиентов, а во второй на поставщиков.
Старый 03.06.2013, 09:13   #3  
trud is offline
trud
Участник
Лучший по профессии 2017
 
947 / 1297 (45) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
ну можно и просто 3 поля сделать - код клиента, код поставщика и тип.
Т.е. получается это такой мягкий намек - не использовать Relation вида Field fixed. все бы хорошо если бы они сами это повсеместно не использовали
Старый 03.06.2013, 09:16   #4  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,501 / 2600 (96) +++++++++
Регистрация: 16.01.2004
Адрес: Москва
Записей в блоге: 5
Цитата:
Сообщение от trud Посмотреть сообщение
Самое удивительное что Microsoft для своих таблиц как-то умудрились отключить эту проверку, т.е. к примеру на InventPosting ошибка не возникает.
файл с таблицей прилагаю
В макросе SysBPCheckIgnore нет InventPosting => где-то в логике бестпрактисов зашиты различия (может там RelationType какой установить надо). Можно поставить breakpoint в \Classes\SysBPCheck\addError и посмотреть в чем разница
__________________
blog | twitter
Старый 03.06.2013, 09:19   #5  
S.Kuskov is offline
S.Kuskov
Участник
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
3,292 / 1625 (61) ++++++++
Регистрация: 28.04.2007
Адрес: Калуга
Цитата:
Сообщение от trud Посмотреть сообщение
ну можно и просто 3 поля сделать - код клиента, код поставщика и тип.
Сейчас подумалось, наверное при использовании наследования можно попробовать поле с контрагентом оставить в базовой таблице, а в дочерние таблицы вообще никакие поля не добавлять, а использовать их только для размещения на них Relation. Получится?
Старый 03.06.2013, 09:21   #6  
trud is offline
trud
Участник
Лучший по профессии 2017
 
947 / 1297 (45) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
дебагинг выявил следующее
у таблицы есть невидимое св-во EnforceFKRelation(можно увидеть в xpo). если оно в 0, то данная ошибка не возникает. по умолчанию оно стоит в 1.
просто поменять его в xpo и загрузить таблицу с перезаписью не получится, оно игнорируется. если удалить таблицу и загрузить заново, то да, меняется.
К сожалению в моем варианте таблица много где используется, да и данные есть, т.е. вариант с удалением не проходит
Старый 03.06.2013, 09:26   #7  
trud is offline
trud
Участник
Лучший по профессии 2017
 
947 / 1297 (45) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Цитата:
Сообщение от S.Kuskov Посмотреть сообщение
Сейчас подумалось, наверное при использовании наследования можно попробовать поле с контрагентом оставить в базовой таблице, а в дочерние таблицы вообще никакие поля не добавлять, а использовать их только для размещения на них Relation. Получится?
нет, так нельзя, в Relation доступны только поля таблицы
да и непонятно, как работать с такими таблицами - все переводить на View? т.е. простейший while select не сделаешь
Старый 03.06.2013, 10:56   #8  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,501 / 2600 (96) +++++++++
Регистрация: 16.01.2004
Адрес: Москва
Записей в блоге: 5
EnforceFKRelation устанавливается на таблицах, импортированных из 2009.

Мне кажется, с наследованием правильно сделать два наследника с двумя разными полями.
__________________
blog | twitter
Старый 03.06.2013, 11:21   #9  
DSPIC is offline
DSPIC
Боец
Аватар для DSPIC
MCP
Лучший по профессии 2017
Лучший по профессии 2014
Лучший по профессии 2009
 
1,035 / 1082 (39) ++++++++
Регистрация: 11.04.2008
Адрес: Минск
Я очень надеюсь, что это недоразумение пофиксят\переделают в ближайших релизах. Я так и не нашел, как это зарезолвить по-человечески.
А пока я делаю так, :
  1. Экспорт таблицы в XPO
  2. Меняем блокнотом тип релейшена на PKFK
  3. Импортируем обратно

Название: 6-3-2013 10-17-11 AM.png
Просмотров: 2234

Размер: 16.8 Кб
__________________
Мой блог
За это сообщение автора поблагодарили: wojzeh (1).
Старый 03.06.2013, 11:34   #10  
S.Kuskov is offline
S.Kuskov
Участник
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
3,292 / 1625 (61) ++++++++
Регистрация: 28.04.2007
Адрес: Калуга
Цитата:
Сообщение от belugin Посмотреть сообщение
Мне кажется, с наследованием правильно сделать два наследника с двумя разными полями.
Ну вообще-то говоря да, в общем случае типы данных у этих полей ведь не обязаны совпадать.

Интересно а как теперь в стандарте реализуется механизм связи с использованием перечисления TableGroupAll?
Старый 03.06.2013, 12:23   #11  
trud is offline
trud
Участник
Лучший по профессии 2017
 
947 / 1297 (45) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Цитата:
Сообщение от S.Kuskov Посмотреть сообщение
Интересно а как теперь в стандарте реализуется механизм связи с использованием перечисления TableGroupAll?
Думаю все как и было. просто Microsoft умеет сбрасывать EnforceFKRelation у таблиц
Старый 03.06.2013, 13:24   #12  
kashperuk is offline
kashperuk
Участник
Аватар для kashperuk
MCBMSS
Соотечественники
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,360 / 2080 (78) +++++++++
Регистрация: 30.05.2004
Адрес: Копенгаген, Дания
Цитата:
Сообщение от trud Посмотреть сообщение
Думаю все как и было. просто Microsoft умеет сбрасывать EnforceFKRelation у таблиц
Ну, это сильно сказано.
Думаю все зависит от наличия или отсутствия заполненного поля LegacyID
Старый 03.06.2013, 14:16   #13  
MikeR is offline
MikeR
MCT
Аватар для MikeR
MCBMSS
Лучший по профессии 2015
Лучший по профессии 2014
 
1,626 / 622 (24) +++++++
Регистрация: 28.11.2005
Адрес: просто землянин
Цитата:
Сообщение от kashperuk Посмотреть сообщение
Думаю все зависит от наличия или отсутствия заполненного поля LegacyID
Стало интересно, а система как-нибудь проверяет корректность введенных в это поле данных при импорте или можно любое значение ставить?
X++:
 LegacyId            #1517
__________________
Axapta book for developer
Старый 03.06.2013, 14:36   #14  
kashperuk is offline
kashperuk
Участник
Аватар для kashperuk
MCBMSS
Соотечественники
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,360 / 2080 (78) +++++++++
Регистрация: 30.05.2004
Адрес: Копенгаген, Дания
Вряд ли как-то проверяет.
Возможно только такие банальности, как отсутствие дублей и т.п.
Старый 03.06.2013, 18:25   #15  
lvan is offline
lvan
Участник
Аватар для lvan
Лучший по профессии 2014
 
820 / 73 (4) ++++
Регистрация: 15.04.2011
Записей в блоге: 1
Я тоже с этой проблемой столкнулся, тоже докопался до этого EnforceFKRelation и забил в итоге
Так до сих пор и выдает эту ошибку BP при компиляции.
Старый 03.06.2013, 18:44   #16  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,501 / 2600 (96) +++++++++
Регистрация: 16.01.2004
Адрес: Москва
Записей в блоге: 5
Есть макрос SysBPCheckIgnore, куда можно добавлять пути, которые не надо проверять на специфические ошибки
__________________
blog | twitter
За это сообщение автора поблагодарили: trud (1), S.Kuskov (1).
Старый 27.01.2021, 17:28   #17  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,436 / 2297 (83) +++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
up-ну тему.

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

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

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

Последний раз редактировалось Logger; 27.01.2021 в 17:53.
Старый 27.01.2021, 18:59   #18  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,436 / 2297 (83) +++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от 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.
Если предположить что в нашей табличке для клиентов миллионы записей, а для поставщиков - десятки, то возможно оптимизатору проще будет запросы строить и не промахиваться с оценками.

Последний раз редактировалось Logger; 27.01.2021 в 19:08.
За это сообщение автора поблагодарили: sukhanchik (6).
Старый 27.01.2021, 22:53   #19  
Владимир Максимов is offline
Владимир Максимов
Участник
КОРУС Консалтинг
 
1,526 / 1009 (37) ++++++++
Регистрация: 13.01.2004
Записей в блоге: 3
Это не о том

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

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

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

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

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


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

Не проводка выбирает с кем будет работать, а проводку создают из заранее известного документа. Поэтому TransType в ней выполнял не управляющую, а информационную (справочную) функцию. Избыточно с точки зрения нормализации (лишнее поле). Вот его и выбросили. А что связи искать потребуется больше времени, так это не аргумент
__________________
- Может, я как-то неправильно живу?!
- Отчего же? Правильно. Только зря...
Старый 28.01.2021, 13:40   #20  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,436 / 2297 (83) +++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Ну а как бы вы решили проблему описанную в заголовке темы ?
По другому спроектировали бы данные ?
Обошли бы проверку? Как ?
Теги
best practice, enforcefkrelation, forein key, relation

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
axtools: AX2012 R2 hotfix available to improve compile speed Blog bot DAX Blogs 1 01.05.2013 03:53
Axilicious:Running AX2012 R2 locally on Windows 2012 Server booted directly from VHD Blog bot DAX Blogs 0 16.04.2013 08:13
emeadaxsupport: The 'view details' feature will not work on an EDT field when the field has a relation defined in the 'table references' subnode. Blog bot DAX Blogs 0 26.01.2013 02:14
ukax: Dynamics AX2012 R2 Launches!!!! Blog bot DAX Blogs 0 04.12.2012 19:11
Universal Field Changer new version for Microsoft Dynamics AX2012 Blog bot DAX Blogs 0 18.01.2012 04:34
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 21:55.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.