2010-09-21 1 views
1

Мы хотим создать отчет в Microsoft Dynamics AX 2009, чтобы показать всех сотрудников, которые работали над производственным заказом.Отчет AX: одна ошибка со связанными источниками данных

в источниках данных для этого отчета мы перетащить-н-уронил
ProdTable (PT), который является внутренним присоединился PRODID и DataAreaID к
ProdJournalRoute (Pjr), который является внутренним присоединился EmplID и DataAreaID к
EmplTable (et), где мы ищем имя сотрудника с помощью метода name().

Этот отчет дает некоторую забавную вывод:

pjr.TransDate pjr.EmplID et.EmplID et.name() 
2010-07-20 05820 
2010-07-20 05820  05820  Doe, John 
2010-07-20 05820  05820  Doe, John 
2010-07-21 00341  05820  Doe, John 
2010-07-21 00007  00341  Snow, Jon 
...   ...   ...   ... 

(Columns and rows snipped) 

См? Где-то в соединении между ProdJournalRoute и EmplTable EmplID получает одно смещение линии.

Теперь я мог бы, конечно, просто скопировать name() метод из EmplTable к ProdJournalRoute столу и опускать EmplTable присоединиться в целом, но я боюсь, что это только откладывает проблему: что я могу сделать, чтобы получить мой присоединиться к работе? Должен ли я использовать ручной запрос и использовать его в качестве источника данных для отчета?

(PS:! мог, возможно, кто-то с необходимыми правами пользователя очистить все эти
[[[microsoft] dynamics] AX]тегов Спасибо)

+0

PS: но никто не имеет репутации выше 2000. Дайте мне взлеты :) –

ответ

0

Получил это работу.

Я немного неохотно признает, что решение было простым: когда, из подсказок, я восстановить все это с нуля, я добавил все свои ProdJournalRoute полей и EmplTable полей в EmplTable _Body дизайна вместо ProdJournalRoute _Водный, как я сделал первый раз, и это имело значение.

Я все еще не совсем понимаю, как и где отчет связывает данные, которые он отображает. Я бы подумал, что запрос должен выполняться в целом, объединив все задействованные таблицы, чтобы просто не мог получить такого рода несоответствие данных между таблицами, но там он: источник <DS> только обновлен только в <DS> _Общая конструкция. Используя этот источник данных в структуре дизайна источника данных, который соединен дальше, запрос получает странные результаты: либо он не инициализирован, либо он показывает старые данные, полученные из присоединения к предыдущей записи.

Еще раз спасибо за ваши мысли, мистер Кьельдсен.

0

Проверьте связь между таблицами ProdJournalRoute и EmplTable.

Установите ProdJournalRoute.relations на Да или добавьте отношения вручную.

+0

Спасибо, но, как я писал: ProdJournalRoute является внутренним соединенным (или связанным, если хотите) EmplID и DataAreaID с EmplTable. Установка отношений в Да в свойствах ProdJournalRoute ничего не меняет, извините. –

0

Мне кажется, что таблицы фактически не объединены в запросе, но уровень абстракции, создающий базовые запросы, запускается сначала с одним выбором в самой внешней таблице, а затем выполняется запрос для «соединенных» таблиц. Это может объяснить, почему в первой строке нет данных из EmplTable. Я предполагаю, что запрос к EmplTable не возвратил данные, достаточно быстрые для фреймворка.Взгляните на свойство FirstFast источника данных, а также то, что он делает в MSDN: http://msdn.microsoft.com/en-us/library/aa842737(AX.10).aspx

Возможно, я ошибаюсь. Единственный способ узнать, это попробовать запустить SQL-запрос в базе данных.

+0

Хорошая идея. Я пробовал это, но обнаружил, что переключение FirstFast на No дает те же результаты. –