22.04.2009, 14:37 | #1 |
Участник
|
Виснет настройка прав доступа
Axapta 3.0 SP6 виснет при попытке войти в настройку прав доступа даже пользовательской группы Admin...
Что делать? |
|
22.04.2009, 14:45 | #2 |
MCITP
|
Может подождать подольше? Она никогда быстро не открывалась..
__________________
Zhirenkov Vitaly |
|
22.04.2009, 14:48 | #3 |
Участник
|
1час мало?)
|
|
22.04.2009, 15:40 | #4 |
Программатор
|
Может быть что и мало. Смотря какая машина у Вас думает. Придется декодировать Вам Аксапту
|
|
22.04.2009, 16:58 | #5 |
Участник
|
Зависает тестовая база. 3х-звенка. Начала зависать после обновления приложения и развертывания бэкапа с рабочей базы..
|
|
22.04.2009, 17:25 | #6 |
Administrator
|
Ну для начала имеет смысл проверить табличку AccessRightsList. Если по ней слетели индексы - то вот она, родимая - причина ваших висяков. Т.е. Вам следует сначала выполнить синхронизацию, а уж затем смотреть права.
А вообще - к примеру в Оракле - возможно развернуть бекап без индексов, после чего запустить переиндексацию (которая будет дооолго по времени хрюкать)
__________________
Возможно сделать все. Вопрос времени |
|
23.04.2009, 00:43 | #7 |
Участник
|
Таже бага в Ах 4.0
У меня бывает в 4 тоже виснет. Правда если входишь в Админ - показывает. После загрузки админа, можно уже и другие группы редактировать...
|
|
23.04.2009, 06:32 | #8 |
Administrator
|
Цитата:
Потом следует обратить внимание со стороны БД на таблички AccessRightsList, SysSecurityForm*. Именно эти 3 таблицы (первая особенно) влияют на построение дерева. Можно написать несложный джоб, который будет удалять из них лишние записи (после удаления/переименования пункта меню, по которому были записи в таблице - записи не изменяются и остаются в виде мусора. С контрольками на формах - там еще больше мусора). Надо проверить индексы по табличкам (их наличие, возможно их нужно пересоздать т.к. они кривые), возможно таблицы следует дефрагментировать в БД. Также следует проверить соотношение групп полльзователей, пользователей и доменов. У вас кол-во групп больше кол-ва пользователей? Тогда делаем индивидуальные группы и у вас будет кол-во групп = кол-ву пользователей. Этим вы уменьшите кол-во записей в таблицах. Но это все общие рекомендации. С каждым случаем надо разбираться отдельно
__________________
Возможно сделать все. Вопрос времени |
|
|
За это сообщение автора поблагодарили: Волчара (1). |
23.04.2009, 17:22 | #9 |
Участник
|
Модификаций точно нет, попробую переиндексировать таблицы
|
|
23.04.2009, 17:37 | #10 |
Участник
|
Цитата:
Цитата:
Сообщение от sukhanchik
Для начала неплохо было бы убедиться, в отсутствии модификаций в этой функциональности...
Потом следует обратить внимание со стороны БД на таблички AccessRightsList, SysSecurityForm*. Именно эти 3 таблицы (первая особенно) влияют на построение дерева... Надо проверить индексы по табличкам (их наличие, возможно их нужно пересоздать т.к. они кривые), возможно таблицы следует дефрагментировать в БД. Также следует проверить соотношение групп полльзователей, пользователей и доменов. У вас кол-во групп больше кол-ва пользователей? Тогда делаем индивидуальные группы и у вас будет кол-во групп = кол-ву пользователей... Удаление индексов у этих 3х таблиц в SQL и синхронизация не помогают. Пользователей больше чем групп.. |
|
23.04.2009, 22:38 | #11 |
Administrator
|
Цитата:
Так в отношении "лишних записей" Вы проверили? Сейчас джоба под рукой нет - но суть в том - что делается select по AccessRightsList и проверяется есть ли те MenuItem, Tables, Security Key и т.д. в АОТ, которые присутствуют в таблице. В отношении отсуствия модификаций. ТОЧНО НЕТ? А как Вы определяли? Только по форме? Меня интересуют классы SysSecurity*. И можно взять пару форм Sys*Security. Второй вариант - большое кол-во записей или отсутствие индекса на таблице. Ну нет другой причины....
__________________
Возможно сделать все. Вопрос времени |
|
23.04.2009, 22:46 | #12 |
Участник
|
А может, сначала просто продебажить - где конкретно виснет? Потрассировать там запросы всякие...
|
|
24.04.2009, 09:10 | #13 |
Программатор
|
|
|
24.04.2009, 09:15 | #14 |
Участник
|
Открываю закладку с настройками прав, при этом начинает работать скролл барр сверху формы. Пока работает скролл-барр две закладки пропадают. Скролл-барр дошел до конца, форма отвисла, аксапта отвисла, закладки не появились, работать нельзя.
|
|
24.04.2009, 09:36 | #15 |
Administrator
|
Ну а какая ситуация с классами и формами SysSecurity*? (есть ли свои перекрытия?)
Кстати. Есть еще одна хорошая рекомендация. Глобальная компиляция. Я наблюдал как висло резервирование только из-за того, что внедренцы, заливая модификации хпо-шниками на рабочую не удосуживались делать глобальную компиляцию. А сделанная глобальная компиляция сразу выявила порядка трех десятков ошибок компиляции, после чего резервирование работать перестало в принципе - но уже стала вылетать "нормальная" трассировка стека и ясно стало где была ошибка компиляции. Ее исправление восстановило работу системы.
__________________
Возможно сделать все. Вопрос времени |
|
24.04.2009, 14:24 | #16 |
Участник
|
|
|
28.04.2009, 14:58 | #17 |
Участник
|
что еще посоветуете?
|
|
28.04.2009, 15:16 | #18 |
Administrator
|
Тогда можно проверить в БД:
1. Наличие индексов на табличке ACCESSRIGHTSLIST в БД: I_65526ELEMENT (RECORDTYPE, PARENTID, ID), некластерный и I_65526GROUP (GROUPID, DOMAINID, RECORDTYPE, PARENTID, ID, ELEMENTNAME) кластерный. 2. Выполнить команду DBCC REINDEX ('ACCESSRIGHTSLIST') в БД лдя дефрагментации таблицы. Пока у меня варианты заканчиваются
__________________
Возможно сделать все. Вопрос времени |
|
|
За это сообщение автора поблагодарили: decoder (1). |
28.04.2009, 15:20 | #19 |
Administrator
|
И еще. Проверьте "лишние" записи по AccessRightsList.
Еще - посмотрите будут ли тормоза - если очистить таблички SysSecurityForm*? (ессно удалять записи нельзя, но проверить скорость на пустой табличке можно)
__________________
Возможно сделать все. Вопрос времени |
|