DataAreaId and ProjDataAreaId in AX 2012 Query

[Cardagant]

Всем привет,

Занимаюсь кастомизацией кубов для AX 2012. R3

Имею следующую ситуацию:
Таблица TSTimesheetLine имеет 2 поля, определяющих dataArea - это, собственно, dataAreaid (поле компании) и ProjectDataAreaId - поле определяет компанию проекта.

Мне нужно, не задействуя поле dataAreaid, создать релейшн в квере на 2 поля ProjectDataAreaId и ProjId.

Но, создавая эти релейшены в квери, и добавляя квери как источник данных дял вью, просматривая эту вью через SQL Server, я вижу 3 релейшена, помимо этих двух, присутствует ещё и обычный DataAreaid, что ломает мне картину.

Подскажите, есть ли какие-то варианты решения этой ситуации?

Заранее благодарю.

[Cardagant]

Любые мысли по этому поводу?

[twilight]

Не создавать view в Аксапте, а написать запрос в Visual Studio в проекте для кубов?

[Cardagant]

Цитата:

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

Не создавать view в Аксапте, а написать запрос в Visual Studio в проекте для кубов?

Спасибо за ответ.

Рассматривал этот вариант.Вьюха имеет целый ряд Computed columns, которые оперируют энумерейшенами. Если преобразовывать это всё в datasourceView запрос на уровне проекта VS, то это всё ставится просто числами, не совсем надёжными на мой взгляд.

Как считаете?

[-DocSerzh-]

Прямое обращение к СУБД, минуя Axapta
?

[Cardagant]

Спасибо за ответ.

Пробежался я по теме, которую вы порекомендовали.
Не совсем я понял как это поможет решить мою проблему.

А именно, когда computed columns в Аксапте оперируют энамами, они используют стандарный Аксаптовский вид - Энам::элемент, что на SQL уровне конечно же заменяется числами, но в данном случае надёжность гарантирована Аксаптой.

Если же написать тот же запрос на стороне проекта куба в датасорс вью (Named Query), то получается, что все энамы следует заменить на числа, что абсолютно не гарантирует никакой надёжности.

[Cardagant]

Если имеются в виду некоторые джойны на таблицу энамов, которая описана в теме, то не понимаю как реализовать в данном случае computed columns.

[twilight]

Если вычисления не используют это релейшен, то сделать промежуточные view с вычислениями и уже прямой запрос с релейшеном по этим view.
Текущие значения перечислений обычно не меняются, а при добавлении новых в любом случае придется вносить изменения во view. Поэтому не должно быть особых проблем с надежностью.

[S.Kuskov]

Цитата:

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

просматривая эту вью через SQL Server, я вижу 3 релейшена, помимо этих двух, присутствует ещё и обычный DataAreaid, что ломает мне картину.

А при просмотре этого представление внутри аксапты лишней связи нет?

Query query = new Query(queryStr("вашQuery"));
info(query.datasourceNo(1).toString());

Здесь уже есть лиший relation?
Если так, то все лечится отменой автоматических связей и установкой только нужных в методе init() запроса.

[sukhanchik]

Цитата:

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

Здесь уже есть лиший relation?

Нет, здесь релейшна нет. Связка скорее всего устанавливается ядром при наличии поля DataAreaId в таблице. CrossCompany тут тоже не помогает.

[S.Kuskov]

Цитата:

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

Нет, здесь релейшна нет. Связка скорее всего устанавливается ядром при наличии поля DataAreaId в таблице. CrossCompany тут тоже не помогает.

В какой момент? При сборке View?

А если соединяемый таблицы предварительно обернуть в самостоятельные View? DataAreaId всё равно туда просочится?

[Cardagant]

Цитата:

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

В какой момент? При сборке View?

А если соединяемый таблицы предварительно обернуть в самостоятельные View? DataAreaId всё равно туда просочится?

Могу сказать, что пробовал TSTimesheetLine к самостоятельной вью ProjTable, так как во вью поля датаареа в наличии, а именно добавляются ядром, то по ним связь строится.