Установка версии 6 на сервере в расширенной конфигурации.

[Akina]

Вчера столкнулся с очень серьёзной проблемой, решение которой заняло почти день. Причём решать её пришлось самостоятельно - техподдержка развела руками.

Используется ПК Смета.РУ. Текущая версия была 4, с последним апдейтом. Требовалось выполнить обновление до версии 6. Версия - клиент-серверная, но с применением локальных ключей. Однако необычна конфигурации сервера БД, потому о ней дополнительно.

Сервер работает под управлением Windows 2003 EE SP 2 со всеми апдейтами. На нём установлены 2 инстанса Firebird 1.5.0.4306, работающих на портах 3050 (classic mode) и 3051 (superserver mode), с именами сервисов gds_db и gds_db_3051 соответственно. Каждый инстанс обслуживает по 2 БД, в т.ч. инстанс 3050 - БД Смета.РУ. Остальные БД - из разряда 7*24, допустимое время простоя - не более 30 минут.

Первый звоночек прозвенел при первом же запуске инсталлятора. Он заявил, что не будет работать при загруженном BDE, без вариантов продолжения. Выяснилось, что ему необходима выгрузка обоих инстансов Firebird. Почему - непонятно.
После остановки обоих сервисов инсталлятор запустился и произвёл обновление базы данных. Однако в процессе инсталляции он самовольно, не задавая вопросов и не давая сообщений, произвёл установку ещё одного инстанса Firebird, причём в superserver mode на порт 3050, и установил Guardian.
Само собой появление ещё одного инстанса сервера, причём конфликтующего с существующим, привело к значительным проблемам. Даже остановка поставленных без спроса сервисов и восстановление запоротого файла конфигурации не смогло до конца решить проблему. Само собой использование штатного деинсталлятора для удаления этих сервисов было невозможно. В результате пришлось проводить достаточно долгий процесс ручной чистки реестра от установленных инсталлятором сервисов и виртуальных устройств, корректировки ссылок на общие модули и пр.

Ну и теперь собственно сам вопрос - где брать инсталлятор для продвинутых конфигураций? Который не будет проявлять самодеятельности, будет сообщать о каждом своём шаге, будет использовать те ресурсы, которые ему предоставлены, а не те, которые ему хочется доустановить. И без инсталлятора Firebird внутри (тем более запускаемого в silent-mode).

[Mikle]

В настоящий момент такого инсталлятора не существует. Причем я даже не уверен, что он в ближайшее время появится. За 7 лет существования инсталлятора Ваш случай с двумя установленными FireBird едва ли не первый.

[Akina]

В таком случае такой, наверное, технический, вопрос... даже два.
1) При установке нетрудно перед установкой остановить сервис, а в процессе отследить и заблокировать запуск инсталлятора Firebird, и вместо его запуска стартовать существующий сервис... но как к этому отнесётся инсталлятор самОй сметы? Продолжит? или ему надо непременно вернуть от запускаемого процесса нулевой код ошибки?
2) При дефолтной установке инстансу Firebird даётся умолчательное имя Firebird Server - Default Instance, и аналогичное имя - формируемому виртуальному Legacy-устройству. После установки Firebird инсталлятор сметы ориентируется на эти имена, или ему достаточно того, что есть с кем разговаривать на localhost:gds_db?

[Kir]

Akina, убедитесь, что нет подключений к базе Smeta.ru (попытайтесь переименовать файл DataSD.ssd). Остановите Firebird. Скопируйте базу на любой компьютер, на котором отсутствует Smeta.ru. На этом же компьютере запустите инсталляцию, выберите только серверную составляющую. Установится Firebird и что важно программа "Мониторинга баз данных", на рабочем столе появится соответствующий ярлык. В корневом каталоге инсталлятора есть архив SQL.zip, в нем содержатся скрипты для подъема базы до нужной версии, в Вашем случае с 4-ой до 6-ой, распакуйте архив. Запустите программу, зарегистрируйте базу и "поднимите" ее. Скопируйте базу на ваш сервер + весь набор dll, размещенных в стандартном каталоге установки C:\Programm Files\Firebird_1_5\Firebird\Firebird_1_5\UDF: B_UDF.dll, kUDF.dll, LckUdf.dll, LxUtils.dll, s_udf.dll, в соответствующий каталог у Вас на сервере. Запустите Firebird. Мне кажется, что так будет быстрее.

[aivt]

To Akina:
Будь я хоть отчасти крут как Вы, я бы перед запуском на сервере неизвестного Вам инсталлятора Smeta.ru, сделал бы образ диска. После выше описанных вами злоключений, я бы восстановил образ на сервере и обратился за помощью к специалистам.

Я бы на вашем месте попробовал бы пойти другим менее заумным путем:

1. сначала попробовать поставить Smeta.ru v6 на любой другой "чистой" машине.

2. переименовать имеющуюся на сервере папку Stroysoft в Stroysoft4.
3. поправить путь к базе данных в файле \StroySoft4\Smeta.ru\Client\Data\GDBPath.net так как поменялось имя папки Stroysoft на Stroysoft4.
4. поправить путь к Smetaru.exe в свойствах ярлыка на рабочем столе, так как папка Stroysoft на клиентских машинах была переименована в Stroysoft4.

5. повторить п.п. 2 - 4 на всех клиентских машинах.

6. скопировать с чистой машины на сервер папку Stroysoft.

7. Проверить и при необходимости поправить на сервере путь к базе данных в файле \StroySoft\Smeta.ru\Client\Data\GDBPath.net.

8. на клиентских машинах запустить инсталлятор Smeta.ru v6 и произвести с его помощью деинсталляцию клиентов Smeta.ru v4 (при этом клиент Smeta.ru v4 на самом деле не будет удален, так как папка Stroysoft на клиентских машинах была переименована в Stroysoft4, но инсталлятор решит, что ему удалось удалить Smeta.ru v4)

9. на клиентских машинах повторно запустить инсталлятор Smeta.ru v6 и произвести с его помощью установку клиентов Smeta.ru v6 в папку Stroysoft при этом прописав путь к базе данных Smeta.ru v6 в файле \StroySoft\Smeta.ru\Client\Data\GDBPath.net.

10. Ручками перекопировать UDF файлы относящиеся к Smeta.ru v6 из папки C:\Program Files\Firebird\Firebird_1_5\UDF с чистой машины на сервер.

Так как Smeta.ru v4 у вас уже работала на данном сервере, то она бы и продолжила работать после переименования папки Stroysoft на Stroysoft4.

Новая версия Smeta.ru v6 должна заработать из папки StroySoft после такой установки без нарушения работы сервера и Firebird.

[aivt]

Поднять базу с 4 версии до 6 тоже вариант, но я так никогда не делаю по трем причинам:

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

во-вторых кроме технического обновления скриптов версии базы с 4 до 6 версии есть еще и обновление ее содержимого (данных), которое не произойдет после подъема скриптов базы до новой версии. Если после этого обновлять еще и данные, то это займет еще неделю если конечно знаете что делать и какие данные обновлять.

в-третьих чтобы избавиться от груза старых объектов накопившихся в старой базе я своим клиентам рекомендую старые объекты оставлять в старой базе, а новую базу ставить чистую и начинать в ней новые объекты. С локальным ключом пользователь всегда может запустить две версии программы и 4 и 6, а следовательно будет иметь доступ к старой и к новой информации. Со временем старая информация содержащаяся в старой базе станет не нужной, поэтому пользователю не придется запускать обе версии программы. Как правило мои клиенты за время между выходами новых версий базы 1-> 2 -> 3 -> 4 -> 5 -> 6 накапливают в базе такое количество объектов, что работать с ним практически не возможно (за год 6-8 тысяч объектов). Мной зафиксирован у клиентов рост базы (за счет объектов) до 8Гб за год!!! Поэтому лучше все же начинать новую базу при переходе на новую версию, а не поднимать старую базу до новой версии.

Наличие на сервере и на клиенте двух папок Stroysoft и Stroysoft4, а также двух ярлычков на рабочем столе меньшее из возможных зол.

[Semenov]

...кроме технического обновления скриптов версии базы с 4 до 6 версии есть еще и обновление ее содержимого (данных), которое не произойдет после подъема скриптов базы до новой версии...

Немножко непонятно, что имеется ввиду под обновлением данных.
Если это установка новых версий баз, видов цен, индексов и т.п. - согласен...
Если это изменение данных, связанное с изменением принципов хранения, алгоритмов работы и т.п., необходимые при переходе на новую версию - то данная проблема решена разработчиками еще до выхода первой версии Smeta.ru, т.е. обновление скриптов происходит далеко не "технически", если оно производится инсталлятором или программой "Мониторинга баз данных"

[aivt]

Совершенно верно, имеется ввиду обновление нормативных баз, видов цен, индексов, мониторинга, шаблонов типовых расчетов, методической информации и т.д. Все это после подъема верссии необходимо подгрузить ручками, а затем граматно сделать необходимые настройки "под ключ". Даже у меня это занимает целую неделю при условии, что я знаю досканально что нужно делать. Сколько времени это же будет делать пользователь стоит только гадать, так как он сам понятия не имеет что ему нужно делать. Поэтому я никогда и ни кому не советую поднимать базу - лучше всего пусть это сделает тот кто умеет, а пользователю запишет готовый инсталлтор не просто с новой версией программы, но и полностью укомплектованный загруженными в базу обновленными данными и настроенный под "ключ". Такую работу способны выполнить региональные представители, в результате программа устанавливается клиентом за 5 минут и не требует дополнительно делать НИЧЕГО кроме ввода пароля и подключения лицензии !!!

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