Поиск размеров висит AX клиент? - PullRequest
0 голосов
/ 03 апреля 2020

У меня есть интерфейс импорта (не кодированный мной), который импортирует данные XML и создает записи LedgerJournalTable (1) и LedgerJournalTrans (1..n).

При обработке измерений LJT код сначала проверяет, существует ли измерение в AX, а затем вставляет данные в поле измерения [x]. Однако в случае, если измерение не существует, пользователю показывается предупреждение после завершения цикла импорта, но данные по-прежнему вставляются как .

И когда Пользователь переходит к строке LJT после завершения импорта, ошибочное значение отображается в поле измерения. При щелчке по поиску / раскрытию этого измерения поиск не открывается и клиент AX зависает. Ctrl + break восстановит его, но поиск никогда не откроется. Вы можете удалить значение, сохранить, и проблема не исчезнет. Вы можете вручную ввести существующее значение и сохранить, и проблема все еще будет сохраняться. Проблема распространяется и на браузер таблиц.

Любая идея, почему это происходит и как это можно исправить, за исключением сохранения ошибочного значения в первую очередь (я понятия не имею, почему это делается таким образом в первое место)?

Заранее спасибо.

Ответы [ 2 ]

0 голосов
/ 08 апреля 2020

Отредактировано: Итак, хотя в БД произошла ошибка, фактический виновник был найден: стандартный код AX, создающий временные данные для поиска измерений - в Dimensions.insert () был код мода, который записал XML файл каждого измерения были обновлены или вставлены. В этом случае это заняло так много времени, что клиент повесил трубку. Я поместил код внутри предложения if следующим образом:

if(!this.isTemp())
{
  // offending code
}

Проблема решена.

0 голосов
/ 03 апреля 2020

Дайте мне знать, если я правильно читаю.

  1. Пользователь запускает некоторый процесс для импорта записей таблицы / трансформации LJ из XML.
  2. Если неверное измерение находится внутри XML, оно помещает данные в поле транс-размера LJ [x], даже если оно недопустимо, и выдает предупреждение пользователю.
  3. Пользователь просматривает журнал и видит неверные данные и пытается использовать поиск, чтобы исправить его, но поиск зависает / падает.

Мне кажется, проблема может заключаться в том, что вы отправили кучу плохих данных в AX, и поиск пытается использовать недопустимые отношения таблица / edt.

Если я прав, вам нужно напрямую от go до SQL и запросить таблицу трансляций главной книги и найти любой неверные данные измерений и исправление / удаление.

Я подозреваю, что существующие неверные данные вызывают сбой поиска, а не только какие-то неверные данные, которые вы импортировали и просматриваете.

Возможно, причина проблемы в том, что пользователь импортировал неверные данные, получил предупреждение, проигнорировал предупреждение , нажал "опубликовать" как есть (с неверными данными), и теперь он находится в AX? И теперь, когда вы выполняете второй импорт и пытаетесь использовать поиск, это приводит к сбою в этом плохом отношении данных.

...