Слетают настройки на платформе SQL у филиальной базы.

[Nik]

Клиент имеет филиальную БД. Платформа SQL 2000 SP4.
Галактика 810 патчи по состоянию 29 февраля 2009 (14 атлантис).

1) Нужен совет по локализации проблемы слетания настроек у пользователей.

Настройки слетают бессистемно по пользоватиелям, дате, офису.
Проявляется на всех филиалах. У пользователей с разними правами.

Настройки слетают в процессе работы. Периодичность от 2 раз в день до 1 раза в две недели.

Проявляется так например: нормально печатают отчеты, а потом вдруг очередной отчет не печатает ФИО гл.буха. Заходим в настройки, а ФИО глав.буха уже пустое, как и название собственной организации. Причем в администраторе настроек стоит дата изменения настройки сегодня, время - минуту назад, а дескриптор не указан.

Более того, со слов клиента, если зайти в журнал, то таблица настроек не изменялась вообще. Если тут же в Галактике настройку вернуть в правильное положение, то в журнале всё чудестно отразится. Такое ощущение что настройки изменяются не на уровне Галактика/Support, а где то ниже. Такое может быть (клиент внешними средствами доступа не пользуется)?

2) У этого же клиента происходят также сбои системы Protect. Сбои становятся видны после выхода/ входа в систему, например утром, когда после загрузки пользователь получает доступ к только к части причитающегося ему меню.

Возможно проблемы 1 и 2 не связанные.

p.s. доставили все патчи по состоянию на вчера. Наблюдаем ...

Как локализовать хотя бы первую часть проблемы?

[sema]

Проявляется так например: нормально печатают отчеты, а потом вдруг очередной отчет не печатает ФИО гл.буха. Заходим в настройки, а ФИО глав.буха уже пустое, как и название собственной организации. Причем в администраторе настроек стоит дата изменения настройки сегодня, время - минуту назад

Теоретически такое возможно, если в процессе работы кто-то из пользователей (а вероятно даже и не один) стартанул модификацию настроек. Причиной может быть наличие отдельной непропатченной установки (например на филиальном сервере ресурсники отличаются от центрального).
Практически у нас была ситуация, когда при запущенной модификации настроек вошел еще один пользователей (админ), и не зная об этом, также запустил (принудительно) модификацию. Результат - напрочь слетели все настройки, пришлось поднимать базу из архива.
Позднее знающие люди объяснили так, что модификация настроек - операция сугубо эксклюзивная, и ее нужно запускать в монопольном режиме доступа к БД. В противном случае результат непредсказуем.

[mike]

C недавних пор в "Администраторе настроек" появился отчет "протокол изменения настроек".
См. ПиР 101.38717. Позволяет увидеть кто и когда какие настройки менял. Если отчет не поможет, то видимо дело не в Галактике, а в протекте или MSSQL.
Проверка реестра настроек теоретически тоже может поудалять значения настроек.
Для филиальной БД это может произойти если меняется структура филиалов, удаляются пользователи. Поэтому неплохо бы знать запускалась ли проверка. Или протектом закрыть доступ к этому пункту меню.

[mike]

Ситуация описанная Масловым Сергеем могла иметь место. Начиная с C_Tune_810150 при начали модификации настроек в БД выставляется семафор и повторная модификация уже не запустится.
Странно, что никто из пользовательй раньше не жаловался. Правится это легко, польза как
оказываетяс может быть существенной.

[den]

.... а потом вдруг очередной отчет не печатает ФИО гл.буха. Заходим в настройки, а ФИО глав.буха уже пустое, как и название собственной организации. Причем в администраторе настроек стоит дата изменения настройки сегодня, время - минуту назад, а дескриптор не указан.

....
Как локализовать хотя бы первую часть проблемы?

Раз модифицируется - значит кто то меняет значение настройки. Можно пойти несколько нетривиальным способом. Как известно, триггер у мсскуля объехать никак - все изменения все равно через него идут. Таким образом, можно отследить в нем (t$tuneval_u) изменение определенной настройки (в данном случае настройку 'Главный бухгалтер' из группы "Собственная организация") путем логгирования кто изменил и когда. Или вообще сгенерить там (в триггере)некорректную ситуацию и поймать с поличным такого галактического клиента - в этом случае на клинета вылезает ошибка "внутрення ошибки инте-са доступа .....подробности в ms70log"

[ilshat]

Как известно, триггер у мсскуля объехать никак -

Вот насмешили :)

EnableTrigger - http://technet.microsoft.com/en-us/libr ... L.90).aspx

Код: Выделить всё

ENABLE TRIGGER { [ schema_name . ] trigger_name [ ,...n ] | ALL }
ON { object_name | DATABASE | ALL SERVER } [ ; ]

Disable Trigger - http://technet.microsoft.com/en-us/libr ... L.90).aspx

Код: Выделить всё

DISABLE TRIGGER { [ schema_name . ] trigger_name [ ,...n ] | ALL }
ON { object_name | DATABASE | ALL SERVER } [ ; ]

[den]

Ну да..есть такая фича. Но, думаю, вряд ли она заюзана Хотя проверить это не помешает

[cruger]

Как известно, триггер у мсскуля объехать никак -

Вот насмешили :)

EnableTrigger - http://technet.microsoft.com/en-us/libr ... L.90).aspx
[/code]

Вы первую строчку топика читали?