Евгений_86,

могу Вас заверить, что это весьма веселое занятие :)

Первое, что Вам понадобиться это документация. Если она у Вас есть, то делайте все по шагам.

У меня при переносе на Галактики (ms sql server 2000) было два "залета":
1. Когда устанавливал sql server 2000, кодировку default поставил не ту, что указана в документации (i_sql.chm).
2. После восстанавления пользователей Галактики, умудрился их удалить :)

P.S. Лицензия нашего предприятия предусматривает доступ в Support только к администрированию групп и пользователей. Так что если у ваша лицензия дает доступ к Экспорту/Импорту в Support, то берите документацию и смело делайте по шагам установку приложения и базы.

Евгений_86,

что тут скажешь? Успехов :)

Все доки у меня на работе, так что пока не нет возможности.
Посмотрите тут может быть есть.

MasygreenБазу в Бакап..
на новом серваке поставить галактику, поднять NapServer востановить БД.
А далее по инструкции - супер гемор по востановлению пользователей и прав...

Никакого гемора нет. У Галактики на этот счет есть пошаговая инструкция по восстановлению учеток.
Одно "НО" - если в лицензии на support не предусмотрен доступ к модулю sql, то тогда действительно будут проблемы с восстановлением учеток, так как придется делать один из шагов средствами sql.

Перемещение базы данных на другой MS SQL Server выполняется путем восстановления на нем резервной копии базы данных (Backup Database), созданной на 'старом' сервере. Операции создания/восстановления резервной копии выполняются стандартными средствами MS SQL Server.

Однако при этом возникает проблема, суть которой заключается в том, что backup базы данных содержит ее пользователей (Users), но не содержит логины (Logins). Поэтому после восстановления базы данных на другом сервере, для обеспечения работоспособности системы логины необходимо восстанавливать отдельно.

Таким образом, для перемещения базы данных на другой сервер БД необходимо выполнить следующие действия:

1) Если новый MS SQL Server расположен на другом компьютере, то необходимо:


установить на новом сервере БД вспомогательную службу napsrv.exe системы Галактика ERP (см. п. Обновление вспомогательной службы Галактики ERP).

Для этого предварительно на новый сервер БД нужно скопировать каталог \DB_INST из серверной части системы.

Примечание: Установка вспомогательной службы является обязательным этапом, так как в процессе ее установки в базе данных master MS SQL Server формируются необходимые внешние хранимые процедуры.


Откорректировать файл csetup.ini, расположенный в папке \SETUP серверной части системы Галактика ERP, добавив в него следующие параметры:

[Main]
DB_INSTALLED=<имя восстанавливаемой базы данных>;
DBDriver=MS70DRV.DLL
[MSSqlServer]
DB_<имя восстанавливаемой базы данных>= <сетевое имя компьютера, на котором установлен сервер БД>
IN_<сетевое имя компьютера, на котором установлен сервер БД>= <значение>
где <значение> имеет формат:

<протокол>:<адрес_сервиса_для_протокола>[<порт>],

где

<протокол> должен соответствовать протоколу сервиса (см. п. Возможные варианты протоколов). По умолчанию ncacn_ip_tcp

<адрес_сервиса_для_протокола> должен быть записан в формате, соответствующем протоколу (см. п. Возможные варианты сетевых адресов);

<порт> должен быть записан в формате соответствующем выбранному протоколу (см. п. Возможные варианты портов) и соответствовать порту сервиса. По умолчанию 1997

Значение данного параметра определяется с помощью Менеджера серверов и служб Галактики по полю Конфигурация клиента окна =Конфигурация вспомогательной службы= (см. п. Порядок настройки службы).


Откорректировать файл install.ini, расположенный в папке \EXE серверной части системы Галактика ERP, изменив в нем следующие параметры:

[Main]
DBDriver=MS70DRV.DLL
[Bases]
Base1=<имя восстанавливаемой базы данных>
Path1= = <значение>
где <значение> совпадает со значением параметра IN_<сетевое имя компьютера, на котором установлен сервер БД> файла csetup.ini (см. выше).

BaseCount=1

Откорректировать настройки клиентских частей системы (альтернативой является переустановка клиентских частей):

- В конфигурационном файле (galnet.cfg) клиентской части откорректировать параметр SQLDriver.SQLServer, задав в нем настройки для нового сервера БД.

- Откорректировать в ODBC Data Sources описание System DSN для восстанавливаемой БД (изменить имя сервера на новое).

Примечание: считается, что при восстановлении базы данных ее имя не изменится. В противном случае дополнительно необходимо откорректировать параметр DataBase.DataBaseName файла galnet.cfg и изменить имя БД в ODBC Data Sources (System DSN) на рабочих станциях.


На рабочей станции администратора аналогично выполнить необходимые настройки для комплекса Support.

2) Восстановить базу данных на новом сервере из резервной копии (Restore Database), используя средства MS SQL Server.

При задании параметров восстановления базы данных проверьте правильность задания местонахождения файлов базы данных (вкладка Options окна =Restore database=) и при необходимости измените пути.

3) Отключить подсистемы прав доступа (Protect) и журнализации (Journal), выполнив в Query Analizer в восстановленной БД скрипт:

update x$journalconfig set typejournal=0
update abonents set protecton=0 from x$journalconfig
where abonents.officeno=x$journalconfig.officeno
4) Войти в комплекс Support под заведомо не существующим пользователем. Далее по тексту будем обозначать его как <NEWUSER>. Запуск Support в этом режиме может быть выполнен с использованием параметров командной строки /u: и /#user:, например:

start x:\support\exe\support.exe /u:NEWUSER /#user:NEWUSER
В модуле SQL открыть таблицу x$users на редактирование (SQL => SQL => Просмотр структуры БД) и выставить в поле xu$type для этого нового пользователя значение 1.

Данное действие переопределяет нового пользователя <NEWUSER> как администратора.

5) Средствами модуля Экспорт/Импорт экспортировать таблицу x$users в dbf и выйти из комплекса Support.

6) Для обеспечения возможности выполнения шага 7) необходимо заблокировать триггер x$users_d таблицы x$users восстановленной БД, выполнив следующие действия:


В Enterprise Manager для таблицы x$users войти в режим Design Table;

Открыть Trigger Properties и выбрать триггер x$users_d;

Изменить оператор CREATE TRIGGER следующим образом (вставить оператор RETURN, не изменяя 'тело' триггера):

CREATE TRIGGER X$USERS_D ON X$USERS FOR Delete AS RETURN

Нажать [OK] и выйти из режима Design Table.

7) Войти в комплекс Support под пользователем <NEWUSER> (см. шаг 4).

В модуле SQL открыть таблицу x$users на редактирование и удалить всех пользователей кроме пользователя <NEWUSER>.

Запомнить значение NRec этого пользователя (поле ATL_NREC) для использования при выполнении последующих шагов.

Выйти из Support.

8) Вернуть в исходное состояние (разблокировать) триггер x$users_d таблицы x$users восстановленной БД, выполнив следующие действия:


В Enterprise Manager для таблицы x$users войти в режим Design Table;

Открыть Trigger Properties и выбрать триггер x$users_d;

Изменить оператор CREATE TRIGGER следующим образом (удалить оператор RETURN, не изменяя 'тело' триггера):

CREATE TRIGGER X$USERS_D ON X$USERS FOR Delete AS

Нажать [OK] и выйти из режима Design Table.

9) Открыть в Enterprise Manager список групп (ролей). Удалить все группы с префиксом GR#, кроме последней, для которой символы после префикса должны совпадать с NRec нового пользователя, с учетом поправки на замену старшего разряда. Эти группы могут быть привязаны к пользователям, поэтому перед удалением группу (роль) необходимо отвязать от пользователя (remove в окне свойств роли).

10) Убедиться, что в настройках сервера разрешено изменять системные таблицы (режим SQL Server Properties, вкладка Server Settings, флаг Allow modifications to be made directly to the system catalogs).

11) Удалить всех пользователей из таблицы sysusers восстановленной БД (за исключением пользователя <NEWUSER>), выполнив в Query Analizer следующий скрипт:


delete sysusers where (name like '\%' or uid > 3 and
(issqluser=1 or isntuser=1)) and name <> '\<NEWUSER>'
delete sysusers where name like 'GR#%' and
name <> 'GR#<NRec_пользователя_NEWUSER*>'
* - NRec нового пользователя, с учетом поправки на замену старшего разряда.

После выполнения этого скрипта в таблице sysusers должны остаться dbo, guest, public, gr#<NRec_пользователя_NEWUSER>, information_schema, предустановленные роли db_<роль> и новый пользователь.

12) Удалить в Enterprise Manager все динамические хранимые процедуры восстановленной базы данных (Stored Procedures) с префиксами:

DT, EQ, FT, GE, GR, LE, LS, LT, ML, NT, PS, RE

Скрипт для удаления хранимых процедур может быть получен путем выполнения в восстановленной базе данных запроса:

select 'drop procedure '+name from sysobjects where xtype = 'P' and name like '__0___________________________'
13) Выполнить в Query Analizer (или MS SQL Server Management Studio) для восстановленной БД:

truncate table xx$hashvalues
14) Войти в комплекс Support под пользователем <NEWUSER> и в модуле Экспорт/Импорт импортировать таблицу x$users из dbf, с использованием способа импорта 'добавление'.

На сообщение о попытке импорта системной таблицы ответить [Yes].

В журнал импорта (файл Journal) будет выдано сообщение о том, что последняя запись, соответствующая новому пользователю, не вставилась в таблицу из-за дублирования ключа - так и должно быть.

15) Пересчитать права всем пользователям (модуль Права доступа).

Данная операция необходима для восстановления прав в MS SQL Server.

16) При необходимости, включить подсистемы прав доступа (Protect) и журнализации (Journal) (последнюю, сначала придется 'выключить', т.к. в настроечной таблице осталась старая информация).

Выйти из комплекса Support.

17) Войти в систему Галактика ERP, проверить работу и, при необходимости, удалить нового пользователя <NEWUSER>.

Это была выдержка из i_sql.chm :)