Галактика в вопросах и ответах

2 вопроса
1. Установка нового напсервера, вернее обновление старого.
Каждый раз это происходит по разному (((.
По инструкции надо всех выгнать, запустить 2 скрипта, и затем установить новый нап с помощью ms_inst....
При установке последнего напа, мне пришлость остановить старый и только после этого удалось установить новый.
Так всех или только у меня ?

2-й вопрос по правам пользователей, не входящих в группы.
Установил все обновления на резерный сервер, восстановил копию базы и обнаружил, что у пользователей, не входящих группы, нет никаких прав ни на базу, ни на таблицы ни на что.
Раньше так не было.
Подскажите, что не так?

1. Установка напа на тестовый сервер как правило не требует его ручного останова, на рабочем же возможно остаются какие то сессии, которые мешают его стопорнуть в автомате или политика безопасности блокирует. Насчет 2 скриптов не знаю. В описании к патчманагеру написан порядок обновления. Сначала db_inst, потом patchmanager(я еще сразу сапорт обновляю, копии всех exe делаю обязательно).
2. Про пользовательские права уже 100 раз писали - лучше их не использовать. Кроме того на mssql, oracle возможно использование групповых ролей, что существенно сокращает время на расчет прав. Для правильного переноса в i_sql.chm написана целая инструкция в 20 пунктов.

Наверное я непонятно написал.
1. Речь идет не об обновлении через патчменеджер, а об обновлении (в MS SQL версии Галактики) службы напсервера.
2.Роли использовать не хочу, т.к. время пересчета прав небольшое.
Немного не понял про пользовательские права.
Всю жизнь с ними работаем
может мы о разном?

1. Если перед установкой напа рестартовать MSSQLSERVER , то всегда нормально почему то . И стопорнуь его руками тоже не особо напрягает.
2. Пользовательские права плохи тем, что если у человека поменяется круг обязанностей, то на настройку придется тратить больше времени. Опять же если есть 2 работника с одинаковыми обязанностями, и вдруг что то поменяется в функционале (типа как заюзали spdocs в расчет ЗП) , то придется каждому настраивать. Поищите на форуме - вроде пара раз эта тема обсуждалась. Кроме времени пересчета есть случаи падения производительности(и даже кто то вообще жаловался на полное зависание) в MSSQL - но все это когда пользователей очень много(скажем больше 100).

По пункту 1. согласен.
Но в инструкции написано не так. (или я ее давно не читал)
2. Опишу проблему более подробно.
Есть база с обновлениями начала года. Экспортирую таблицу xusers.
Восстанавливаю копию базы. В EXE установлены все обновления. Импортирую xusers.
У пользователей не входящих в группы в Supporte , нет прав ни на что, ни на меню, ни на таблицы, ни по условиям.
Если восстановлю базу на те же EXE, что и исходная база, то с правами все нормально у всех пользователей.
Вот это меня и смущает.
Если я установлю обновления на текущую базу не пропадут ли у меня права пользователей, не входящих в группы (в supporte )

В описании к патчам говорилось об изменении шифрации системных таблиц.
Вот например про первасив, видимо MSSQL это тоже касается

И все таки проблема осталась.
Проблема не в шифрации.
При восстановлении (переносе базы на другой сервер MS SQL), у пользователей не входящих в группы не переносятся права по условиям, права на таблицы, видимость меню.

Хочу уточнить проблему. Восстановил базу на другом сервере. Посмотрел права у пользователей, все есть, и права на таблицы, и права по условиям. Далее делаю по инструкции, удаляю из таблицы xusers всех пользователей, затем импортирую их из ранее выгруженного файла. После импорта прав на таблицы и условия нет.
Я так делал несколько лет и все получалось, почему перестало работать непонято.

И все таки никак не получается с правами пользователей после восстановления базы (SQL).
Полсе удаления из таблицы x$users пользователей, чистится и таблица X$RIGHS, где хранятся данные о правах на пользователя.
Таблица TableRights, где права на группы остается неизменной.
После импорта пользователей в таблицу x$users, в таблице X$RIGHS ничего не появляется и соответственно у пользователя нет прав на таблицу и т.д. (кроме групповых, они есть).
Вижу на форуме народ восстанавливает базы из копий, похоже только у меня проблема ?
Я теперь после восстановления не удаляю таблицу x$users, но хотелось бы понять, что не так делаю ((((.

тут вопрос больше в правах в sql. Я теперь x$users не удаляю, а выгружаю и гружу с ключом r. После это пересчитываю права со всеми галками. А ну да - еще зайти админом надо как то, но это тоже возможно.

edward_K писал(а):тут вопрос больше в правах в sql. Я теперь x$users не удаляю, а выгружаю и гружу с ключом r. После это пересчитываю права со всеми галками. А ну да - еще зайти админом надо как то, но это тоже возможно.

1. Прав у меня в SQL много
2. Ключ r - это с замещением ?
3. Ну с админом это не сложно, сначала просто вошел в Support, затем заменил пользователя? которым вошел, на админа (прямо в таблице)
4.Спасибо.

Пытаюсь выяснить в ТП почему не получается.

1. права не у вас, а в sql на всех пользователей- они сами не очень переносятся, тем более если FullLoginName включен.
2. да с замещением. В этом случае ничего не удаляется и типа все нормально - а логины в sql создаются.
есть еще вариант с сохранением/восстановлением прав в сапорте - но он как раз все грохает и потому иногда сбоит.
3. Ну я обычно протект перед сохранением не отрубаю, а часто вообще беру ночной архив и все - поэтому у меня проблемы.
Приходится сносить админа в security базы, а потом задавать такие же права в security сервера на базу, как на рабочую. Если там такого логина нет, то создаю руками с нужным паролем. При nt авторизации мож и попроще будет.

Не очень понятно зачем надо удалять и восстанавливать таблицу с пользователями.
Ну когда первый раз это делаеи, то в SQL нет этих пользователей, они эти действием создаются (так мне кажется).
Но я потом в эту же базу многократно восстанавливал, т.е. пользователи в SQL уже есть.