09.03.2004, 15:17 | #1 |
Участник
|
Аксапта падает при открытии журнала табелей
Может кто встречался с таким траблом - при открытии журнала табелей (модуль "Расчеты с пересоналом") Аксапта падает - причем только в случае если главное меню открыто в полноэкранном режиме. Падает клиент, сервер продолжает нормально работать. Аксапта 3.0 SP2
Привожу содержание файла AxaptaCrash.log: Axapta Crash Dump File for Axapta build 1951.17 (Oct 9 2002 11:51:44) Dumped : Tue Mar 09 15:08:38 2004 Crash : Exception 0xc0000005 caught (unspecified) in thread 0x690 of process 0x6a8. ------------------------------------------------------------- --# FV EIP----- RetAddr- FramePtr StackPtr Symbol 0 .V 0068f9c3 00000000 00000000 0012e890 Mod: ax32[ax32.exe], base: 00400000h Stackdump exit code 487 (Attempt to access invalid address) |
|
09.03.2004, 15:22 | #2 |
Шаман форума
|
|
|
09.03.2004, 15:36 | #3 |
Участник
|
Похоже, но от этого не легче...
|
|
10.03.2004, 12:25 | #4 |
Участник
|
Добрый день!
Вступление: В Ax 3.0 SP2 CIS есть стандартная функциональность по настройке порядка следования полей для каждого пользователя. Это было и раньше в 2.5 и 2.1, правда при выходе из формы и/или из Аксапта порядок полей для каждого пользователя не сохранялся (насколько я помню). По существу: Если поперетаскивать поля «Ставка…» и «Time…» (поменять их местами), причем одно из полей "Ставка..." попытаться разместить между полями «Time…» (в строках ежедневного табеля - журнал табелей модуль "Расчеты с пересоналом"). А потом выйти из формы и вновь зайти, то система сообщит об ошибке и вылетит в операционную систему. "Лечил" эту ошубку удалением пользователя и созданием его вновь. Думаю есть более легкие пути решения, но не было времени искать. С уважением |
|
10.03.2004, 16:54 | #5 |
Участник
|
Более легкий путь - это сделать сброс пользовательских настроек юзверя.
Сервис - параметры - использование данных - сброс. при этом естественно сбрасываются и все фильтры, формы пользователя, что для многих обидно и горько. |
|
11.03.2004, 05:49 | #6 |
Соучастник
|
Мне пересоздание пользователя почему-то не помогло. Будем исследовать дальше.
__________________
View Anton Soldatov's LinkedIn profile |
|
11.03.2004, 06:28 | #7 |
Участник
|
2 Hobo:
Спасибо за совет, при случае попробую. 2 Антон Солдатов: Антон, я такое проделывал под 2-х уровневой, мне помогло (сколько раз пробовал - столько раз и помогло). Глупый совет, если Вы работаете под 3-х уровневой, попробуй "убить" кэш. |
|
11.03.2004, 09:11 | #8 |
Соучастник
|
Цитата:
Изначально опубликовано mpa
Глупый совет, если Вы работаете под 3-х уровневой, попробуй "убить" кэш.
__________________
View Anton Soldatov's LinkedIn profile |
|
11.03.2004, 09:42 | #9 |
Участник
|
Мне тоже не помогает ни пересоздание юзера, ни очистка настроек юзера, ни удаление лога
|
|
11.03.2004, 09:49 | #10 |
NavAx
|
1. Присоеденеяюсь к Hobo, но только можно найти записи, относящиеся к форме. Т.е. Сервис\Параметры\Использование данных\Все данные, потом фильтруем recordType = Form и Наименование = RPayTblJournal (Наименование = RPayTblDayHourTrans).
2. Удалите кеш-файлы, котрые в Win2000 находятся тут: C:\Documents and Settings\UserName\Local Settings\Application Data\*.aoc |
|
|
За это сообщение автора поблагодарили: SerAl (1). |
30.03.2004, 09:21 | #11 |
Участник
|
Кажется, выход один - дожидаться выхода следующих SP и HF.
Мы можем ускорить этот процесс, если будем каждый crash.log отправлять в MBS. PS. Мне часто помогало удаление кеша. Хотя через некоторое время краш опять происходил. ИМХО, это тонкая ошибка где-то в ядре. |
|
Теги |
ошибка, расчеты с персоналом |
|
|