Ошибка 487 (Попытка обращения к неверному адресу)

[P^ilk^A]

Всем добрый день!
Версия Аксапты 3.0. Делаю отчеты в Аксапте, которые выводят данные в Excel. Ранее никогда такой ошибки не замечалось, а теперь она вылетает уже на двух отчетах.
Ошибка в следующем: Нажимаем на пункт меню с отчетом, отчет открывается в Excel (все данные выводятся правильно), но Аксапта сама закрывается и в файле AxaptaCrash выводится следующий текст с ошибкой:
Axapta Crash Dump File for Axapta build 1951.2410 (Aug 19 2003 19:44:15)
Dumped : Tue Mar 18 11:07:32 2014

Crash : Exception 0xc0000005 caught (unspecified) in thread 0x9c of process 0xaf8.
-------------------------------------------------------------

--# FV EIP----- RetAddr- FramePtr StackPtr Symbol

0 .V 0047f6c6 00000000 92000000 0012f4ac Mod: ax32[ax32.exe], base: 00400000h

Stackdump exit code 487 (Попытка обращения к неверному адресу)

[gl00mie]

Цитата:

Сообщение от P^ilk^A

Axapta Crash Dump File for Axapta build 1951.2410 (Aug 19 2003 19:44:15)
Crash : Exception 0xc0000005 caught (unspecified) in thread 0x9c of process 0xaf8.

Обновите эту древность хотя бы до KR3 (build 1951.7609) - пропадет куча косяков, подобных этому.

[P^ilk^A]

Спасибо за ответ. Поговорю с начальством по поводу обновления. Я понимаю что у нас доисторическая Аксапта стоит
Я так понимаю это косяк в самой Аксапте, т.е. если будет отказ от начальства по поводу обновления, то надо искать как обойти эту ошибку.

[gl00mie]

В данном случае не только Аксапта доисторическая, но и версия ядра доисторическая даже по меркам Аксапты 3.0. Версия ядра KR3 - последнее публично выпущенное в 2006-м году обновление ядра, стабильное, проверенное на многих проектах. После него на протяжении примерно двух лет выходили еще "частные" hotfix'ы ядра. На одном крупном проекте используется сборка 3.0.1951.7647 (выпущена в 2007-м), еще на одном некоторое время работали на 3.0.1951.7669 (выпущена в 2008-м), но потом выяснилось, что в ней, видимо, добавлено слишком много каких-то отладочных проверок, из-за чего ощутимо снижаласть, по сравнению с KR3, производительность взаимодействия с СУБД. Так что в результате все равно откатились на KR3.
Подумайте сами: между выпуском вашей сборки ядра и KR3 прошло 3 года, при этом номер сборки увеличился на 5200 - это число коррелирует с количеством нововведений и исправленных ошибок в ядре. У вас проявилась лишь одна из ошибок ядра, но на сколько граблей вы еще не наступили? Зачем самостоятельно бодаться с ошибками ядра, если на куче других внедрений уже наступили на те же и многие другие грабли, зарегистрировали ошибки у вендора, куча программистов эти ошибки воспроизвела, исправила, протестировала и выпустила обновление?

[P^ilk^A]

Спасибо!