Построение перекрёстных ссылок

[Paul_ST]

Столкнулся со следующей проблемой: из одного приложения (рабочего) в другое (тестовое) скопировал с замещением файлы слоёв usr и usp. Вся разработка ведётся только на этих слоях. После этого удалил индексы, сделал глобальную компиляцию, синхронизацию. Прошёл все шаги в контрольных списках обновления и установки - до построения перекрёстных ссылок. При запуске последней процедуры - Аксапта валится минут через 15. Сообщение в виндовом логе ни о чём не говорит - "Faulting application ax32.exe, version 3.0.1951.4070, stamp 42fc7283, faulting module ax32.exe, version 3.0.1951.4070, stamp 42fc7283, debug? 0, fault address 0x003e80d5."
Используем - Axapta 3.0 SP4, Oracle 9.
Дополнительная глобальная компиляция + синхронизация не помогают.
Что можно поделать?

[gl00mie]

Цитата:

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

Прошёл все шаги в контрольных списках обновления и установки - до построения перекрёстных ссылок. При запуске последней процедуры - Аксапта валится минут через 15. Используем - Axapta 3.0 SP4, Oracle 9. Что можно поделать?

Перейти на другую версию ядра Ядро AX3.0SP4 «знаменито» дикими утечками памяти, и если вы посмотрите на динамику изменения объема памяти, которая отжирается AOS'ом и/или клиентом при построении перекрестных ссылок, то увидите, что объем этот постоянно растет до ненормальных величин. Кроме того, даже если с Божей помощью и такой-то матерью вам все ж удастся построить перекрестные ссылки, утечки памяти все равно будут постоянно давать о себе знать. Так, при работе тонкого клиента обычным делом может быть отжирание 256Мб и более при том, что в нормальной ситуации это значение держится на уровне 20-50Мб.
Если боитесь использовать KR, возьмите хотя бы ядро из SP5 - там эти проблемы были решены.

PS. Хмм, вы же вроде уже наступали на грабли с SP4

[miklenew]

Посмотрите как устроены таблицы xRef...
Не помню если Аксапта вылетает, остаются ли ссылки которые уже создались или нет. Если да посмотреть последний recId. Чё за объект.
Если не сохраняет.
Можно по insert написать вставку в файл, отловить какая последняя запись вставилась.
Посмотреть этот объект и следующий за ним. Откомпилироватьна всякий случай.
Далее написать if c условием этого объекта. Поставить точку останова на этом if. Как дойдёт дело до него, смотреть где фигня.

[Paul_ST]

Собственно, мы перешли на билд 4070 для SP4.
Пробовал смотреть таблицу xRefNames - выбирая запись с максимальным RecId. Строю несколько раз перекрёстные ссылки - каждый раз на разных объектах валится.
Попробовал сделать реиндексацию . Тоже не помогло.

[miklenew]

Цитата:

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

Собственно, мы перешли на билд 4070 для SP4.
Пробовал смотреть таблицу xRefNames - выбирая запись с максимальным RecId. Строю несколько раз перекрёстные ссылки - каждый раз на разных объектах валится.
Попробовал сделать реиндексацию . Тоже не помогло.

У нас тоже sp4 билд 1951. И всё нормально пересчитывается. Правда у нас usr слой ещё не большой. Скорее всего где ошибка с некоректностью данных. Найдёте место где выскакивает, поймёте что некоректно. Хотя если глобальная компиляция прошла без ошибок, странно что она выскакивает. Там же всего лишь пробежка по всему AOT раскрытие всех узлов как представляющие из себя строку так и дизайн. Нахождение в нём объектов AOT. Скорее всего при преобразовании каких нибудь данных во что-то происходит ошибка. Надо трэйсить долго и упорно.

[Paul_ST]

фокус в том, что я обновил тестовую базу по рабочей - взяв от рабочей только два файла слоя + затерев базу для тестовой через подъём бэкапа рабочей. Раньше такое ведь тоже делал. Перекрёстные ссылки строились. Единственно, что раньше переписывал не два файла, а целиком всё приложение. Может какие из файлов ещё тоже требуются? Но по теории не должно быть такого.

[Paul_ST]

похоже, что без этого не обойтись спасибо!