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

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

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

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

! ! !

ПРИМЕЧАНИЕ. Помните, что некоторые продукты Borland жестко запрограммированы на распознавание внутренних версий строк только для Borland. Даже если имя и размещение в файловой системе являются "корректными" для элементов Borland, ограничение строки версии может сделать ваше приложение несовместимым со встроенным сервером. Например, приложения, скомпилированные с использованием оригинальных компонентов InterBaseXpress (IBX), не будут соединяться cfbembed.dll без внесения изменений.

. ! .

Строка соединения, например, WlNSERVER:C:\Program Files\Firebird\Firebird 1 5 \employee.fdb, жестко закодированная в вашем приложении, явно вызовет проблемы при установке вашего программного обеспечения на другой машине. Ваш код должен адаптироваться к размещению базы данных, что неизвестно во время проектирования и часто ограничено локальным (не localhost) соединением. Это не является проблемой, появившейся в случае со встроенным сервером. Нам часто нужно поставлять наше программное обеспечение приложений клиент/сервер с предоставлением пользователям или системным администраторам возможности конфигурирования размещения баз данных в сети и в файловой системе.

Система алиасов баз данных позволяет вам компилировать приложения с "мягкими" путями файловой системы к базе данных. Каждый раз, когда код приложения ссылается на сегмент пути в строке соединения, то используется алиас, и определение размещения в файловой системе становится задачей поиска установок в aliases.conf.

Предположим, например, что вы решили использовать EMPDATA В качестве алиаса. В файле aliases.conf на вашей машине разработки вы указали для алиаса ваш путь:

EMPDATA = C:\Program Files\Firebird\Firebird_1_5\employee.fdb На другой машине это может быть:

EMPDATA = D:\databases\employee.fdb

Это решает вопрос с сегментом пути и исключает один уровень сложности. Причем у вас еще может остаться проблема с протоколом соединения. Могут потребоваться некоторые изменения, если приложение жестко закодировано на имя хоста и формат строки для соединения TCP/IP или именованных каналов.

Утилиты, использующие Services API или старые переключатели менеджера сервисов для удаленного администрирования, должны быть отключены или адаптированы к работе с локальным протоколом. Конкретные меры будут зависеть от того, как реализована ваша архитектура клиент/сервер. Если ваше существующее приложение предоставляет возможности, которые обеспечивают безопасность и стабильность сервера, вам также нужно рассмотреть реализацию обращения приложения к серверу, где по существу обходится идентификация пользователя.

Любая библиотека встроенного сервера, размещенная на машине, где находится и база данных, потенциально является Троянским конем. На уровне сервера средства безопасности оперируют в предположении, что любой пользователь, соединяющийся с базой данных, будет идентифицироваться через базу данных безопасности security.fdb. Однако, когда встроенный сервер подключает клиента, идентификация пользователя с его паролем пропускается. Поскольку любой пользователь способен соединиться с любой базой данных, безопасность сервера будет легко отменена, если только серверная машина не будет защищена физически.

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