|  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. Мне часто помогало удаление кеша. Хотя через некоторое время краш опять происходил. ИМХО, это тонкая ошибка где-то в ядре. | 
|  | 
| Теги | 
| ошибка, расчеты с персоналом | 
|  | 
| 
 |