Установка InterBase и Firebird вручную

KDV, 14.09.2005, 25.11.2006, 25.09.2007, 08.05.2008, 20.05.2008, 20.01.2009, 05.09.2011, 28.02.2012, 15.11.2014, 09.11.2016, 06.03.2023.

В этой статье пойдет речь об установке InterBase и Firebird на Windows, заранее приношу извинения пользователям Unix. Тем не менее, пользователи Unix могут извлечь для себя полезную информацию из этой статьи.

Кому будет полезна эта статья:

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

 

Содержание

• Из каких файлов состоит сервер
• Установка вручную
  • установка сервера
  • установка только клиентской части
    • 32 и 64 бита
  • запуск сервиса
• Установка или обновление "поверх"
• Установка серверов "рядом" и поочередный запуск
• Одновременный запуск
• Firebird 2.x, поочередный и одновременный запуск

Важные файлы

Начнем с того, что после установки Interbase или Firebird на диске образуется определенная структура каталогов с лежащими в них файлами. Я исключу всякие examples, ext, doc, sdk и упомяну только то, что нужно серверу для работы:

• корневой каталог установки. Конечно, это может быть C:\Program Files\Borland\InterBase\... Но может быть и проще – C:\IB75, D:\Firebird.... Дело вкуса. Здесь могут находиться
  • файлы interbase.msg или firebird.msg. В них – сообщения сервера (в основном об ошибках). Файлы отличаются между версиями, поэтому если файл "не тот", то сообщения могут выглядеть бредово (несоответственно ситуации).
  • файлы security.fdb (FB 1.5), security2.fdb (FB2), admin.ib (IB7 и выше), isc4.gdb (все остальные) – это база данных, где хранятся пользователи.
  • файл firebird.conf (FB 1.5 и выше) или ibconfig (все остальные) – файл конфигурации сервера. Также aliases.conf для Firebird 1.5/2.x.
  • только для платных версий InterBase – файлы ib_license.dat, borland.lic, node.tmp 
• bin\
  • собственно, все содержимое каталога bin можно считать важным. Назначение отдельных файлов будет дано дальше по ходу статьи (в Firebird 3 уже нет папки bin, все исполняемые файлы находятся в корневой папке установки сервера).
    ! В Firebird 3.0 и выше файлы из папки bin находятся в корневой папке установки сервера.
• intl\
  • файлы gdsintl.dll, fbintl.dll или ваши собственные dll с альтернативными наборами кодировок.
    ! В Firebird 3.0 и выше кодировки находятся в корневой папке сервера - это набор файлов ICU*.*
• UDF\
  • каталог с User Defined Functions, важен только для ваших приложений, если они используют UDF явно в запросах или косвенно в триггерах и процедурах базы данных.
• plugins\
  • папка с плагинами Firebird 3.0 и выше. Здесь же находятся файлы конфигурации этих плагинов. Плагины могут быть разными - аутентификация, шифрование БД, UDR, и так далее.

Все остальное – лишнее, то есть серверу для работы не нужно. Однако разумеется, в новых версиях серверов могут появиться какие-либо файлы, жизненно необходимые для их работы. Эти файлы можно определить экспериментально.

Ручная установка

Допустим, мы взяли корневой каталог сервера, и хотим из этих файлов получить рабочий сервер на другом компьютере. Сразу оговорюсь по поводу платных версий InterBase – во-первых, лицензия дает право установки сервера только на один компьютер; во-вторых, лицензии InterBase 7.x-2009 "привязываются" к операционной системе, поэтому файлы этих серверов просто так перенести нельзя.
  Создадим на новом компьютере каталог C:\Server. Скопируем в него все содержимое корневого каталога той самой установки, о которой было рассказано выше. Теперь при помощи Start/Run открываем окно cmd (для Windows 7 и выше может потребоваться запуск cmd от имени администратора) для Firebird: для InterBase:
И правда, в каталоге bin есть утилита instreg.exe. Она прописывает необходимую информацию в реестр Windows, указывая умолчательное расположение остальных файлов сервера. В версии Firebird 1.5 и выше указывать путь к корневому каталогу не нужно, утилита сама "соображает" откуда она запущена, и прописывает в реестр правильную информацию. Для InterBase путь указывать нужно, более того, для 7.5 и выше нужно указывать еще и дополнительно имя порта (instance gds_db), т. к. при помощи этого параметра обеспечивается возможность независимой установки нескольких независимых экземпляров InterBase на одном компьютере. Не надо только копировать instreg куда попало и пытаться зарегистрировать сервер оттуда.

У instreg могут быть дополнительные параметры, они не важны, и вы можете увидеть их если запустите instreg без параметров (это безопасно, instreg выводит только информацию о параметрах).
  После регистрации сервера утилитой instreg можно сразу проверить работоспособность сервера в режиме приложения. Начиная с InterBase 6 все "наследники" (Firebird, Interbase, Yaffil) поддерживают ключ командной строки -a для запуска сервера в режиме приложения. В том же окне cmd выполним команду:
Конечно, имя сервера может быть другим. Для Firebird это fbserver (SuperServer) и fb_inet_server (Classic), главное чтобы вы поняли идею. Сразу после указанной команды вы увидите иконку сервера в TaskBar, и сервер почти готов к работе.

В отношении InterBase подобный запуск полезен тем, что в случае отсутствия файла лицензии можно увидеть ошибку "License file is missing or corrupt" (в отличие от "приложения" сервис сообщит об этом только в interbase.log, а его еще надо открыть и посмотреть). Также, в taskbar-меню запущенного как приложение InterBase можно увидеть (в Properties) установленные лицензии.
  Если все-таки при выдаче этой команды произошла ошибка, или сервер не реагирует на попытки подсоединения к нему, то нужно искать ее причину. Скорее всего проблема может быть в двух местах:

1. серверу закрыт Firewall-ом порт 3050, или вообще на компьютере не установлен ни dialup adapter, ни драйвер tcp, ни tcp loopback adapter (если нет ни сетевой карточки ни модема). В этом случае ошибка не выдается, сервер запускается, и "молчит". Опасная ситуация, если на этом компьютере уже запущена альтернативная версия InterBase или Firebird – кто запустился первым, тот и будет обрабатывать все запросы по сети.
2. сервер не нашел одну из runtime-библиотек. Такое случается на "чистых" Windows, где никакое другое ПО (особенно от Microsoft) еще не устанавливалось. Проще всего недостающие файлы обнаруживаются при помощи утилиты filemon с сайта www.sysinternals.com. Скачиваете ее, запускаете, вводите в окне фильтра incude имя exe, который запускаете (в данном случае ibserver.exe, fbserver.exe и т. п.), повторяете команду ibserver -a и смотрите в лог какие файлы пытается загрузить сервер.

• Для InterBase 7.x-XE7 это может быть файл libborland_lm.dll (sanctuarylib.dll). Он находится в каталоге bin, поэтому обычно проблем нет.
• Для Firebird 1.5 и выше это как правило библиотеки msvcp60.dll, msvcrt.dll,
• для Firebird 2.0 – msvcp71.dll, msvcr71.dll,
• для Firebird 2.1 – msvcp80.dll, msvcr80.dll
• для Firebird 3.0 - рантайм msvc10 (инсталлятор vccrt10_win32.msi есть в комплекте)

• рантаймы VC 7.1 (VS2003) и VS 6 мне на сайте microsoft.com обнаружить не удалось

Кроме сервера, возможно, вам потребуется обеспечить работу клиентских приложений на этом же компьютере. Для этого приложениям чаще всего (исторически) нужна клиентская часть – gds32.dll. Эта библиотека находится в том же подкаталоге bin. И ее (gds32.dll) нужно скопировать в каталог, где клиентские приложения могут ее находить. Если приложение всего одно, то gds32.dll можно положить прямо в каталог приложения. Если приложений несколько, то gds32.dll нужно поместить в PATH. Проще всего gds32.dll скопировать в системный каталог Windows (C:\Windows, C:\WinNT, C:\WinXP или как там у вас).

У Firebird 1.5 и выше название библиотеки клиентской части отличается от остальных версий InterBase и Firebird 1.0. Вместо gds32.dll есть fbclient.dll. Этот файл можно переименовать в gds32.dll, однако при этом есть риск, что не заработают или будут работать "криво" приложения или компоненты, которые ориентируются на версию gds32.dll (например, может не работать services api). Специальная утилита instclient.exe (см. дальше) позволяет сделать из fbclient.dll файл gds32.dll с правильной версией (6.3).

Проверьте теперь работу клиентских приложений с этим сервером. Работают? Ну и хорошо. Не работают? Тогда вам придется искать ответ чуть дальше, или в другой статье...

Только клиентская часть

Небольшое отступление по поводу клиентской части. Если речь идет не об установке сервера, а об установке клиентской части на "пустой" компьютер, то разумеется, нам потребуются instreg.exe, firebird.msg/interbase.msg, gds32.dll/fbclient.dll.
  Все это можно сложить в одну папку, и запустить оттуда instreg (если это instreg от Firebird 1.5, то он сам прописывает в реестр путь на 1 подкаталог выше. То есть, его надо запускать из специального подкаталога bin, или просто прописать нужный ключ в реестре самостоятельно). Если в реестре не будет информации о местонахождении файла msg, то клиентская часть постоянно будет сообщать что этот файл не найден. При этом, однако, путь к gds32.dll/fbclient.dll все равно должен быть в PATH, для того чтобы приложения могли найти эту библиотеку.
  Кроме того, в Firebird 1.5 и выше есть утилита instclient.exe. Она очень полезна в нескольких смыслах

• позволяет установить клиентскую часть Firebird одной командой
• позволяет установить клиентскую часть как fbclient.dll, либо как gds32.dll

• позволяет проверить наличие установленной библиотеки fbclient или gds32
  instclient q f или instclient q g соответственно
   
• позволяет удалить уже установленный в системе fbclient или gds32.
  instclient r   f | g

Зачем вообще нужна GDS32.DLL в случае Firebird
Ряд программ (компоненты IBX в Delphi, PHP, ...) требуют для работы не просто gds32.dll (имя библиотеки часто жестко прописано в коде), но и проверяют версию этой библиотеки. Например, в IBX (входящем в поставку Delphi) есть код, который проверяет версию библиотеки, и если она меньше 6.0, то в этом случае компоненты Services API становятся недоступны (в т.ч. пропадает панель этих компонент в Delphi).  Именно поэтому простое переименовывание fbclient.dll в gds32.dll для таких программ работать не будет – версия библиотеки окажется ниже 6.0 (т.к. соответствует версии Firebird, у которого нумерация версий идет с 1.0). instclient как раз и прописывает корректную версию в создаваемый gds32.dll. Ничем другим, кроме версии, такая gds32.dll не отличается от fbclient.dll. Для Firebird выбрана версия 6.2.х, 6.3.х... что больше 6.0.

Помните, что gds32.dll от всех версий InterBase требует наличия в файле services записи то есть, клиент обращается к серверу только по имени порта, а не по номеру. Клиент Firebird не требует данной настройки начиная с версии Firebird 1.0. Теоретически можно использовать клиентскую часть от Firebird для работы с сервером InterBase, если вы не хотите редактировать файл services. Однако это крайне не рекомендуется, особенно в отношении самых последних версий InterBase и Firebird (несовместимость в протоколах).

Если устанавливать клиентскую часть InterBase стандартным инсталлятором (включая опцию Silent Install), то инсталлятор самостоятельно прописывает нужную строку. Однако, если на компьютере производятся манипуляции с поддержкой tcp, например удаление протокола и его повторная установка, то файл services при переустановке протокола будет заменен на новый, и клиент InterBase перестанет обращаться к серверу. Проблему придется исправлять повторным прописыванием указанной строки в services. Причем, если такая строка является последней в файле services, то необходимо добавить в конец файла пустую строку, иначе подсистема tcp не обнаружит эту запись.
 

32 и 64 бита

С появлением 64-разрядных версий InterBase и Firebird появилась возможность работать с этими СУБД из 64-разрядных приложений. Есть два простых правила

1. разрядность сервера не имеет значения. Он может быть 64разрядным, а подключаться к нему можно из 32-разрядных приложений, и наоборот,
2. разрядность клиентской части должна совпадать с разрядностью приложения (или драйвера). То есть, приложение 32бит, драйвер 32бит, gds32.dll или fbclient.dll - тоже 32бит.

Тут есть ряд тонкостей. Если у InterBase 64-разрядная клиентская часть называется ibclient64.dll, то у Firebird клиент и 32-бит и 64-бит называется fbclient.dll, и по свойствам файла невозможно определить разрядность этой dll. Причем, если 32-разрядное приложение пытается загрузить 64-разрядную библиотеку, будет выдано сообщение о невозможности загрузить эту dll, например, а не о том, что разрядность dll не та.

Еще путаница может произойти с драйверами типа ODBC. Если вы используете 64-разрядную Windows, то в настройках ODBC будут показываться по умолчанию только 64-разрядные драйверы ODBC. Соответственно, для их использования должен быть установлен 64-разрядный клиент InterBase или Firebird, и приложение тоже должно быть 64-разрядным.

Для работы 32-разрядных приложений с InterBase/Firebird должен быть установлен 32-разрядный ODBC драйвер (о вызове настроек 32-разрядных ODBC-драйверов под 64-разрядной ОС написано тут) и 32-разрядный клиент.

Как уже говорилось выше, 32-разрядный клиент может работать с сервером любой разрядности – 32-бит или 64-бит.
Проще говоря

• разрядность операционной системы определяет возможность использования сервера и клиента конкретной разрядности - на ОС 64бит можно использовать сервер и клиент 32бит или 64бит, на ОС 32бит - сервер и клиент только 32бит.
• Разрядность сервера Firebird или InterBase для клиента не имеет никакого значения
• Разрядность клиентских библиотек должна соответствовать разрядности приложения. Например, приложение 32бит - значит клиент 32бит (или ODBC 32бит + клиент 32бит, и так далее).
• Приложение с разрядностью 32бит не может работать с клиентом 64бит, и наоборот.

Совместимость клиентских частей между Firebird и InterBase

В последних версиях протоколы передачи данных между клиентом и сервером у Firebird и InterBase уже не совместимы. При неправильном клиенте вы можете получить сообщение
или если клиентская часть совсем старая (от InterBase 4.0 и 5.6)
У Firebird наиболее совместимая со всеми предыдущими версиями библиотека fbclient.dll от Firebird 2.5 (совместимость клиентов 2.5 с сервером Firebird 3.0 - отдельный вопрос, нужно конфигурирование firebird.conf).
У InterBase наиболее совместима с версиями от 6.0 до XE7 - библиотека gds32.dll от InterBase XE. В остальных случаях совместимость отсутствует от клиента к серверу. Например, клиент InterBase 2009 не может подсоединиться к InterBase XE-XE7, а вот клиентская часть InterBase XE7 может подсоединиться к серверу InterBase 2009. Это связано как с изменением протокола передачи данных, так и способа шифрования пароля пользователя.
 

Запуск сервиса (службы)

Мы запустили сервер "как приложение", но это нормально (и удобно) только на машине разработчика. На сервере, в смысле "сервер, который обслуживает клиентские приложения", более правильным является запуск InterBase или Firebird в виде сервиса. Сделать это, разумеется, можно только на тех версиях Windows, которые поддерживают сервисы
Утилита instsvc.exe записывает, удаляет или меняет информацию о запуске сервера в базе сервисов операционной системы. После этой команды, открыв список сервисов, вы обнаружите там InterBase или Firebird. Некоторые могут спросить – а где guardian? Дело в том, что специальный сервис, который бы в случае сбоя сервера мог его перезапускать, не нужен в Windows 2000 и 2003 – эта функциональность отлично настраивается в свойствах сервиса, на закладке Recovery.

Настройте сервис так, как вам нужно – автоматический или ручной запуск, и т.п. Можете его стартовать прямо сейчас, только нужно завершить работу сервера в виде приложения (на иконке в Taskbar нажать правую кнопку, выбрать меню shutdown).

Точно так же как и instreg утилита instsvc без параметров показывает все свои возможные параметры. Кроме того, этой утилитой можно управлять запуском и остановкой сервера-сервиса.

Для Firebird версий до 3.0 требуется специальное указание instsvc, если вы инсталлируете Classic (fb_inet_server.exe) – ключ -с. По умолчанию регистрируется сервис суперсервера (fbserver.exe). В 3.0 архитектура сервера определяется в firebird.conf, и уже никакие параметры командной строки сервиса архитектуру не определяют.

Также, Firebird 2.1 и выше имеет у instsvc опцию -n[ame instance], которая позволяет регистрировать как сервис несколько разных экземпляров серверов (как одной, так и разных версий). Без этой опции Firebird разных версий используют одно и то же имя сервиса – "Firebird Server – DefaultInstance", и в этом случае работать будет только тот сервис, который запустился первым.

У InterBase опция имени сервиса чуть иная – instance [instance_name], где instance_name должно совпадать с именем instance, указанного при регистрации сервиса утилитой instreg (см. выше).

После установки сервиса рекомендуется проверить, установлена ли галочка Allow service interact with desktop в свойствах сервиса. Если нет, то может не работать "локальный" коннект – дело в том, что только в последних версиях Yaffil и Firebird протокол локального коннекта изменен (и например, для Classic он вообще не работает до версии Firebird 1.5.2), а ранее он был реализован через shared memory, что не позволяет "видеть" сервис сервера из другого сервиса (или иногда даже из приложения). Собственно, если вдруг с локальным коннектом есть проблемы – забудьте про него и используйте протокол tcp, например localhost:c:\dir\data.gdb. Все это уже давно описано в FAQ.
 

Установка или обновление "поверх"

Вы теперь умеете устанавливать вручную сервер Firebird или InterBase на новый компьютер. Давайте рассмотрим случай, когда поверх Firebird 1.5.0 нужно установить версию 1.5.2, или установить InterBase 7.5.1 поверх InterBase 7.5.0.
  Самое первое и главное правило – это перед подобными действиями скопировать куда-нибудь весь корневой каталог существующей установки сервера. В случае чего вы сможете удалить неудачный эксперимент, и вернуть весь каталог сервера в его исходном виде обратно. Этим вы избавите себя от необходимости переустановки сервера в случае проблем или неверных действий.

Скопировали? Отлично.

Для Firebird новые версии всегда выпускаются в двух вариантах – как инсталлятор, и как набор файлов. Инсталлятор нас в данном случае не интересует, а вот набор файлов – то что нужно. Это zip, содержащий внутри как раз корневой каталог новой версии сервера!

При его распаковке нужно быть внимательным:

1. zip содержит подкаталоги, поэтому нужно распаковывать файл с опцией Use folder names, причем не сразу в каталог установки, а в какой-нибудь временный каталог, откуда нужные файлы уже можно перенести в каталог установленного сервера;
2. zip содержит файл конфигурации (firebird.conf/aliases.conf или ibconfig) и файл базы пользователей (security.fdb, admin.ib или isc4.gdb). Переписав эти файлы поверх ваших текущих вы лишитесь не только сделанных настроек, но и списка пользователей сервера. Поэтому эти файлы желательно сразу удалить во временном каталоге, куда вы распаковали zip следуя указаниям в пункте 1.

Теперь можно просто весь корневой каталог новой версии скопировать поверх существующего корневого каталога установленного сервера. Если сервер в этот момент запущен, то разумеется, переписать ibserver.exe, fbserver.exe, firebird.exe или fb_inet_server.exe не удастся. Остановите сервер, и перепишите файлы.

Далее, после переписывания новых файлов имеет смысл скопировать новую gds32.dll/fbclient.dll в системный каталог, для того чтобы клиентская часть, используемая приложениями, точно соответствовала версии сервера.

Для InterBase действия немного отличаются, т. к. Borland в последнее время выпускает обновления только в виде полных дистрибутивов. Увы, даже для обновления InterBase 7.5.0 на 7.5.1 вам придется качать с embarcadero.com дистрибутив размером ~60 мегабайт (обновление 7.5.1 SP1 содержит только файлы, и может быть легко установлено "поверх").

Скачали? Теперь выясните, где в вашей текущей операционной системе находится каталог TEMP. Это можно сделать в том же самом окне cmd, откуда производился запуск insreg и других утилит. Выдайте команду и операционная система вам покажет его расположение. Теперь, зная имя каталога, зайдите туда обычным Проводником (Explorer) и удалите все старые файлы и остатки от прошлых инсталляций другого ПО. Каталог temp нам нужен чистым (все файлы удалить не удастся, т.к. наверняка будут такие, которые открыты запущенными в данный момент приложеняими. Это не помешает).

Запустите инсталлятор – нужен ib_install.exe, то есть инсталлятор на Java. Инсталлятор install_windows.exe, находящийся в корне установки InterBase может запустить win32- или java-инсталлятор в зависимости от версии 7.1, 7.5 или 7.5.1. В дистрибутиве java-инсталлятор можно найти в папке \Disk1\InstData\Windows\VM. Если у вас ничего кроме win32-инсталлятора нет, то определять, какие файлы куда он записывает, можно только с помощью FileMon (sysinternals.com).

Запустили инсталлятор? Жмите смело Install Borland InterBase 7.5 – в этот момент инсталлятор распакует нужные файлы в temp, мы их скопируем, а саму инсталляцию производить не будем.

Итак, в TEMP у нас образовался каталог I1126692368 (у вас может быть любое другое имя). В нем находятся подкаталоги InstallerData и Windows. Нас интересует InstallerData/Disk1/InstData. Там находится файл Resource1.zip. Собственно, при других именах каталогов или файлов описываемый метод позволяет примерно на 90% обеспечить успешный результат.

Открываем файл Resource1.zip. А еще лучше его скопировать куда-нибудь, распаковать (с подкаталогами!!!), а инсталлятору InterBase 7.5 сказать Cancel и закрыть его.

Теперь смотрите в каталоги, распакованные из Resource1.zip – здесь как раз все то, что нам нужно для "обновления поверх". C_\IB7.5\win32\Server. Не забудьте про admin.ib и ibconfig – лучше их сотрите в этом каталоге, чтобы случайно не переписать аналогичные файлы в вашей текущей установке.

Поскольку лицензионная информация для этого сервера не менялась, сервер остается работоспособным без необходимости его переустановки.

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

Установка серверов "рядом" и поочередный запуск

Изложенный выше вариант годится, если вам надо на конкретном сервере действительно обновить его версию, и все. Разумеется, речь идет об обновлении так называемых "минорных" версий, а не Firebird 1.0 "довести" до Firebird 1.5, или InterBase 7.0 обновить до InterBase 7.5.

Например, у InterBase 7.0 и 7.5 разные лицензии, и безусловно, разная функциональность. У Firebird 1.0 файл конфигурации называется ibconfig, а у FB 1.5 – firebird.conf, отличаются файлы пользователей, и тоже разная функциональность. Кроме того, может элементарно потребоваться проверка новой версии сервера – как она вообще работает, и есть ли смысл обновлять даже InterBase 7.5.0 до 7.5.1 (сразу скажу – смысл ЕСТЬ)? А если работа идет на Firebird 1.5 и хочется посмотреть на InterBase 7.5.1 на этой же машине?

В этом случае вам нужно устанавливать серверы рядом, то есть "параллельно". Стандартные инсталляторы в силу исторических причин могут "перебивать" друг друга, а даже если сервера и отличаются как Firebird 1.5 от InterBase 7.5, запустить их одновременно не получится (потому что они слушают по умолчанию один и тот же порт tcp). Так что без ручных манипуляций не обойтись.

Допустим, на сервере установлен Firebird 1.5 (или мы устанавливаем его первым, не важно). Надо установить InterBase 7.5, и работать с ними поочередно (можно и параллельно). Последовательность действий следующая:

1. Останавливаем текущий сервер (как приложение или сервис), и убираем в конфигурации сервисов его старт как "автоматический" (меняем на "ручной").
2. Устанавливаем InterBase 7.5 в отдельный каталог (например, C:\IB75), как положено, триальную версию или полную с лицензиями.
3. Останавливаем сервис InterBase, как и в пункте 1.

Теперь на компьютере 2 сервера, причем "центральной точкой входа" у них является gds32.dll, не так ли?

Значит для запуска того или иного сервера нам нужно проделывать следующие действия:

• разрегистрировать в реестре сервер, который установлен в данный момент
• это делается при помощи команды instreg remove
• зарегистрировать в реестре сервер, который нам нужен для работы
• это делается при помощи команды instreg install
• переписать правильный gds32.dll в системный каталог.

Автоматизировать данные действия можно при помощи cmd-файлов. Вот пример файлов, используемых у меня на компьютере

remove_all.cmd
d:\intrbase\bin\instreg remove
d:\ib71\bin\instreg remove
d:\ib75\bin\instreg remove
d:\ib2007\bin\instreg remove gds_db
d:\ib2009\bin\instreg remove gds_db
d:\ya\bin\instreg remove
d:\firebird\bin\instreg remove
d:\firebird2\bin\instreg remove
d:\firebird25\bin\instreg remove
 

fb15.cmd
call remove_all.cmd
d:\firebird\bin\instreg install
d:\firebird\bin\fbserver -a
 

ib8.cmd
call remove_all.cmd
d:\ib2007\bin\instreg install
d:\ib2007 instance gds_db d:\ib2007\bin\ibserver -a
...

Как видите, параллельно сосуществуют InterBase 7.1, 7.5, 2007, 2009, Yaffil, Firebird 1.0, 1.5, 2.0, 2.5. Для всех сделаны такие же cmd-файлы. Раньше, правда, было еще хуже, т. к. в каталоге d:\intrbase\bin находятся порядка 15-ти разных версий ibserver.exe (в том числе и от IB 6.0, для технических целей). И запуск нужной версии был сделан как параметр, а файлы именовались ibserver_6010, ibserver_6016, 6505 и т.п. (в загашнике есть еще "неавтоматизированные" версии InterBase 4.0/4.1/4.2).

То есть, путем несложных манипуляций можно организовать попеременный запуск любых серверов на одном компьютере. Поскольку в данном случае надо четко видеть, какая именно версия interbase или firebird запущена, то никакая инсталляция или запуск сервера как сервиса не производится (в скрипте видите instsvc? нет). Версию сервера можно увидеть наведя мышь на иконку сервера в TaskBar.
 

Замечание. Если кто-нибудь повторит такое даже в минимальном объеме с целью тестирования, не забудьте пройтись по файлам конфигураций, и установить там одинаковые параметры (например, временный каталог, размер кэша и т.п. Иначе тест будет некорректен.

Будьте предельно внимательны при поочередной работе с серверами. Вы можете открыть базу "не тем сервером", в результате чего или база будет обновлена до недопустимой версии ODS, или вы испортите метаданные (несовместимый blr).

Возвращаемся к gds32.dll. В примере командного файла нет команды copy, которая бы копировала правильный gds32.dll в системный каталог. Дело в том, что, как правило, на компьютере разработчика в момент смены сервера уже запущены программы, загрузившие gds32.dll. Тогда их придется выгружать, заменять файл, и загружать снова. Чтобы этого не делать, можно

• если вся работа идет в IBExpert – для каждого алиаса БД указать свою (правильный) клиентскую библиотеку (см. настройки алиаса БД);
• если выработать привычку к своим базам всегда коннектиться через localhost, а не через "локальный протокол", то смена gds32.dll может потребоваться только при серъезных отличиях между версиями. К примеру, gds32.dll от InterBase 7.5 прекрасно работает с Firebird 1.5 и 1.0, но gds32.dll от InterBase 2007 уже не работает с сервером Firebird 1.5 (выдает connection rejected by remote interface);
• конкретному приложению "подложить" рядом правильную gds32.dll.

 

Одновременный запуск

У InterBase и Firebird после установки есть

• каталог по умолчанию, прописываемый в реестре (instreg),
• файл конфигурации, находящийся в каталоге по умолчанию,
• именованные системные объекты (мютексы и т. п.) которые сервер использует при своей работе.

Если перечисленные 3 пункта не конфликтуют между собой у двух отдельно взятых серверов, то их можно запустить одновременно на одном компьютере. Кроме того, Firebird 1.5 и InterBase 7.5 могут быть сконфигурированы так, что две этих версии могут быть запущены одновременно, в любом количестве их воплощений.

Зачем это может понадобиться? Вариантов много. У вас может быть "старая" задача, которую нецелесообразно или сложно переводить на новый сервер, и одновременно "новая" задача, которую нужно реализовать на новой версии сервера. Могут быть две базы, к которым надо давать доступ через свой экземпляр сервера, для повышения надежности. И так далее.

Для обоих серверов (и между собой) для осуществления одновременного запуска нужно соблюдать некоторые правила.

Основное правило – это разведение серверов по разным портам tcp. Для старых серверов InterBase 6.0 и ниже изменить порт сервера можно только при помощи модификации записи gds_db в файле SERVICES. Причем для их же клиента изменить номер порта для соединения с сервером можно только таким же способом. Клиент Firebird 1.0 и выше – напротив, позволяет указать номер порта в строке коннекта с сервером. Для InterBase 7.5 придется конфигурировать SERVICES, добавляя альтернативные строки gds_db – в этой версии серверу можно указать, какое имя порта (не номер) использовать для работы. Сервер Firebird 1.5 позволяет указать номер порта tcp в конфигурационном файле. Таблица совместимости, то есть возможности одновременного запуска, выглядит так:
 

	InterBase <=7.1, Firebird 1.0	Firebird 1.5	InterBase 7.5- XE7	Firebird 2.x
InterBase <=7.1, Firebird 1.0	нет	да	да	да
Firebird 1.5	да	см. дальше	да	см. дальше
InterBase 7.5-XE7	да	да	да	да
Firebird 2.x	да	да	да	да

Дальше описано конфигурирование для запуска Firebird 1.5 и InterBase 7.5 как альтернативного сервера относительно уже работающего на компьютере сервера InterBase или Firebird любых версий. При этом подразумевается, что конфигурация серверов InterBase 7.1 и ниже или Firebird 1.0 никак не модифицируется. 

Firebird

Разные экземпляры сервера должны быть скопированы в разные каталоги, и запускаться из них. instreg в этом случае для FB 1.5/2.x запускать нельзя, если вы хотите стартовать одновременно более одного экземпляра FB 1.5 (или несколько штук FB 2.x), в противном случае все запускаемые экземпляры FB 1.5 (или 2.x) будут "видеть" только один каталог сервера, который последним обновил путь в реестре. instsvc запускать можно, для 2.1 и 2.5 нужно указать разные имена у таких сервисов при помощи опции -n[ame instance].

Механика этого процесса следующая. Допустим, на компьютере установлен FB 2.x в двух разных каталогах. У одного в конфиге прописан порт (см. дальше) 3052, а у другого – 3050. При этом в реестре запись DefaultInstance указывает на папку, где установлен сервер с конфигом измененным на порт 3052.

В этом случае на этой же машине подсоединение по умолчанию (без указания порта) будет идти к серверу на порт 3052. Потому что

• клиент будет искать запись в реестре, указывающую на расположение конфига,
• клиент возьмет конфиг по пути реестра, и возьмет оттуда порт по умолчанию (а он изменен на 3052).

Таким образом, главный момент – удаление записи о пути расположения Firebird в реестре. Далее – открываем firebird.conf, ищем параметр CreateInternalWindow (только в FB 1.5). Его надо установить в 0.

Не забудьте, что символ # в файле конфигурации – это символ комментария. И для того, чтобы изменение параметра вступило в силу, его надо раскомментировать, то есть убрать # перед параметром.

RemoteServiceName – Firebird-у как таковому уже давно (с версии 1.0) для работы клиента или сервера не требуется наличие записи gds_db в файле SERVICES операционной системы. Вы и так можете указать нужное имя порта в строке коннекта.

RemoteServicePort – по умолчанию 3050. То есть, основной сервер будет слушать этот порт, а альтернативный сервер – какой-нибудь другой. Например 3100. Меняем параметр, и для всех приложений, которым надо присоединиться к этому, к имени сервера добавляем /3100. Отдельно имя сервера будет выглядеть так:

server/3100

Целиком строка коннекта может выглядеть так:

server/3100:c:\dir\data.gdb

Этот параметр можно не менять, если Firebird запускается как приложение. Достаточно указать в командной строке

> fbserver.exe -a -p 3070

и сервер будет слушать порт 3070, а не 3050 по умолчанию.

RemoteAuxPort – это номер порта, по которому идут события (регистрируемые компонентами вроде IBEventAlerter). Если события используются, то порт надо указать явно. Главное – не забудьте открыть этот порт в Firewall, если таковой есть у вас на сервере (и где уже открыт порт 3050, и где будет открыт порт 3100 из предыдущего примера). Выбрать надо что-нибудь не конфликтующее с работающими приложениями. Помочь может утилита tcpview опять же с www.sysinternals.com.

На этом этапе все Ok. Теперь, если речь идет об установке двух Firebird 1.5, то сложным моментом является идентичность имен сервисов и ключей в реестре, которые прописывают instreg и instsvc. Информацию instreg надо убрать (instreg remove), и придется самостоятельно создавать альтернативный сервис в базе сервиса. Сделать это можно используя примеры программ управления сервисами из командной строки и интерактивного.

 

InterBase 7.5 и выше

С версии 7.5 появился режим запуска Muti-Instance, то есть возможность стартовать одновременно несколько экземпляров сервера на одной машине. Однако, Borland внедрил в клиентскую часть возможность добавления не номера порта к имени сервера, а добавление имени порта, что в определенном смысле усложняет конфигурирование одновременного запуска. Кроме того, при инсталляции сразу должна быть указана возможность использования режима Milti-Instance, как для первой установки так и для остальных.

Подробно настройки Multi-instance описаны в OpGuide.pdf, здесь можно отметить следующее:

• кроме настройки серверов на разные имена портов, существует возможность маршрутизации подключений к базам данных (re-routing) при помощи таблицы DB_ROUTE, находящейся в базе admin.ib. Таблица маршрутизации настраивается для сервера, который "слушает" базовый порт gds_db 3050. Именно он будет переадресовывать запросы к указанным в таблице базам на другой сервер, прослушивающий другой порт. Это позволяет избавиться от редактирования файла services, и направлять "старых" клиентов на нужный экземпляр сервера.
• дополнительная таблица DB_ALIAS в admin.ib позволяет создавать алиасы баз данных (как в Firebird 1.5, aliases.conf). Алиасы управляются или напрямую редактированием этой таблицы, или ключами -alias_* утилиты gsec.

 

Firebird 2.x, поочередный и одновременный запуск

В Firebird 2.x изменилась схема аутентификации пользователей. Собственно, с внешней стороны все осталось как было, но

• новая база пользователей и паролей называется security2.fdb,
• сервер запрещает подсоединение к security2.fdb.

Кроме этого, шифрование паролей в security2.fdb при включении параметра LegacyHash 0 производится MD5, а не DES, как это было во всех версиях IB/FB. По умолчанию используется совместимый способ (DES).

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

Например, вполне успешно работает одновременный запуск FB 1.5 и 2.0 в конфигурации

• Firebird 1.5, без изменений в firebird.conf,
• Firebird 2.0, в firebird.conf RemoteServicePort изменен на 3070.

 

Итог

Теперь вы знаете практически все тонкости ручной установки InterBase и Firebird. В статье опущен ряд подробностей, например, ключи реестра, которые прописывает instreg – оставлю это в виде "домашнего задания", тем более что на www.sysinternals.com есть утилита regmon, которая очень похожа на filemon, уже упомянутый в этой статье. Также пропущен Firebird Embedded – собственно, никаких отличий от установки "только файлы" здесь нет, разве что не требуется запуск instreg.

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

 

Благодарности

• Спасибо компании Borland и Embarcadero за InterBase.
• Спасибо разработчикам Firebird, а также Firebird Foundation за финансовую поддержку проекта Firebird.
• Спасибо Владу Хорсуну, Дмитрию Еманову и Дмитрию Сибирякову за замечания и поправки.

Обсудить статью на форуме