|
![]() |
#1 |
Участник
|
Когда АОС перестал пускать пользователей, у меня не было времени разбираться, я просто поднял приложение из вчерашнего бэкапа, накатил свежие модификации и инкрементно откомпилировал в них классы. Все заработало, а на выходных провел глобальную компиляцию. Банальное удаление axdat.udb не помогало.
1. Глобальная компиляция не повредит. 2. Файл axdat.udb отвечает за подключенных к приложению пользователей. В нем могут появляться "некорректные" данные (например повисшие сессии) или ошибки в структуре. Желательно его удалять при перезагрузке АОС. |
|
![]() |
#2 |
Участник
|
Так не пробовал. Но пробовал с другим приложением (хранится на том же сервере, что и основное) и другой базой (находится на другом сервере). Запускал само собой в трехзвенной конфигурации. Тоже виснет
|
|
![]() |
#3 |
Участник
|
Цитата:
![]() На счет длинных запросов: у меня недавно был случай, когда открытие дочерней формы с dynalink'ом приводило к "зависанию" минут на 5-7, а дело оказалось всего лишь в отсутствии нужного индекса на таблице. К слову, вы так и не ответили: нашлись ли какие-то изменения в объектах AOT, предшествовашие моменту, когда начались зависания? PS. По поводу точек останова: можно еще вставлять вместо них X++: print funcname(); pause; Последний раз редактировалось gl00mie; 06.03.2008 в 11:11. |
|
![]() |
#4 |
Модератор
|
1. Если хотите, что бы Вам помогли, терпимее относитесь к участниках - он пытаются помочь Вам, хотя это, вообще-то, не их дело.
2. продолжаем рыть - поставьте брэкпоинт на startup класса Info. 3. У меня тоже как-то была такая беда - не отрабатывал брэкпоинт. Так и не понял, что это было. Лечилось: сносом верхнего usp слоя (потому что заливка некоторых модификаций велась через usp слой, потом чистилось), остановкой АОСа, удалением индексов, глобальной компиляцией и синхронизацией с переиндексированием. Какое "па" этого танца с бубнами помогло - не могу знать, но в итоге - заработало. 4. Удачи. С Уважением, Геогий |
|
Теги |
ax3.0 |
|
|