Читать онлайн «Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ». Страница 166

Версии, предшествующие Firebird 1.5.

Это два устаревших параметра, унаследованные от предыдущих версий Firebird. Сейчас они не поддерживаются и исключены из firebird.conf.

Версия 1.5 и выше.

Устанавливает метод вычисления логических значений (полный или сокращенный). Значение по умолчанию (0 = False) задает сокращенное вычисление выражений, содержащих предикаты AND или OR, при котором возвращается результат "истина" или "ложь", когда дальнейшее вычисление оставшейся части выражения уже не повлияет на результат.

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

! ! !

ВНИМАНИЕ! Не рассматривайте этот факт как флаг, который влияет на все логические вычисления, выполняемые в любых базах данных на сервере.

. ! .

Версия 1.5 и выше.

Версия 1.5 учитывает старую ошибку InterBase, которая приводит к тому, что выходные параметры возвращаются клиенту в структуре XSQLDA в порядке, вызывающем у пользователя аллергию. Эта ошибка сохранялась столь долго, что многие существующие приложения, драйверы и интерфейсные компоненты имели встроенные средства для корректировки данной проблемы на клиентской стороне[142].

Версия 1.5 и более поздние учитывают наличие корректировок в API и инсталлируются С OldParameterOrdering = 0 (False). Установите этот логический параметр В True (1), если вам нужно вернуться к старым условиям для совместимости с существующим кодом.

Выбор и установки значений параметров для модулей внешних кодов и файлов данных обсуждаются в конце разд. "Конфигурирование внешних размещений".

Встроенный сервер для Windows имеет те же возможности, что и Суперсервер, за исключением поддержки множества пользователей и защиты по паролю. Клиентская библиотека включена в сервер, и эта объединенная пара выполняет работу как клиента, так и сервера для одного и только одного подключенного приложения.

! ! !

ПРИМЕЧАНИЕ. Встроенный сервер для Windows не поддерживается в версиях, предшествующих версии 1.5.

. ! .

Когда встроенный сервер отыскивает корневой каталог его инсталляции, он игнорирует любые записи в реестре и переменную окружения FIREBIRD. Он трактует как корневой тот каталог, в котором размещается его двоичный файл (fbembed.dll, переименованный в fbclient.dll или gds32.dll).

Вы должны иметь полный набор файлов, требуемых для встроенного сервера, в корневом каталоге каждого встроенного приложения. Если используются внешние файлы (поддержка международных языков, библиотеки UDF, библиотеки фильтров BLOB), встроенному серверу нужно найти в этом корневом каталоге или ниже firebird.conf, а в firebird.conf параметр RootDirectory должен указывать на каталог, в котором располагается файл библиотеки встроенного сервера. См. пример в разд. "Встроенный сервер" главы 1.

Единственным допустимым протоколом соединения является "локальный Windows". Встроенный сервер не поддерживает локальный loopback-протокол или любой из сетевых протоколов.

Поставляемое приложение хорошо сконфигурировано, и у сервера не будет конфликтов с другими запущенными серверами Firebird или клиентами. Серверный процесс будет запущен, как только приложение успешно соединится с локальной базой данных.

Любое приложение, которое уже работает с полным сервером и локальным или удаленным клиентом, будет нормально работать и со встроенным сервером. Четыре детали вы должны учесть в ваших существующих приложениях:

* размещение и именование библиотеки встроенного сервера;

* жестко закодированный путь к базе данных;

* написанные вами утилиты, которые используют удаленный менеджер сервисов;

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

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

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

* Поместите копию библиотеки в корневой каталог каждого приложения и разместите дополнительные файлы и каталоги так, как рекомендовано в главе 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 или старые переключатели менеджера сервисов для удаленного администрирования, должны быть отключены или адаптированы к работе с локальным протоколом. Конкретные меры будут зависеть от того, как реализована ваша архитектура клиент/сервер. Если ваше существующее приложение предоставляет возможности, которые обеспечивают безопасность и стабильность сервера, вам также нужно рассмотреть реализацию обращения приложения к серверу, где по существу обходится идентификация пользователя.