А Ковязин - Мир InterBase. Архитектура, администрирование и разработка приложений баз данных в InterBase/FireBird/Yaffil
Совместимость клиентов и серверов различных версий
Как известно, клиент-серверное приложение, использующее СУБД InterBase, обычно состоит из двух основных частей - клиентской и серверной. Клиентская часть, обычно состоящая из исполняемого модуля приложения базы данных (как правило, ехе-файла) и динамических библиотек, исполняется на клиентском компьютере. Серверная часть - собственно базы данных и серверные модули InterBase, обслуживающие клиентские запросы, - исполняется на компьютере- сервере (подробнее о составе модулей, образующих клиент и сервер СУБД InterBase, см. ниже главу "Состав модулей InterBase").
То, что в результате переустановки InterBase и миграции базы данных вы смените версию сервера InterBase на компьютере-сервере, не означает, автоматической замены клиентов на всех клиентских компьютерах. Обычно необходимо вручную заменить клиентскую часть InterBase на этих компьютерах. То есть обычно клиенты InterBase должны иметь ту же версию, что и сервер. Однако если вы не замените клиентские части, то можете обнаружить, что клиенты от младшей версии InterBase работают со старшей версией InterBase-сервера. Такая совместимость - вполне нормальная, документированная особенность, которая используется для облегчения процесса миграции. Возможность использования клиентов и серверов InterBase различных версий представлена в таблице 4.7.
Табл 4.7. Совместимость клиентов и серверов различных версий InterBase
Сервер от версии
Клиент версии
/диалект БД
InterBase 4.x
InterBase 5.x
InterBase 6.x и клоны
InterBase 4 х
Полная
Полная
Полная
InterBase 5 х
С ограничениями
"
"
InterBase 6 х и его клоны /диалект 1
Неустойчивая
С особыми свойствами
"
InterBase 6.x и его клоны /диалект 3
"
"
"
В таблице 4.7 на пересечении версии клиента и версии сервера (для 6.x - с учетом диалекта базы данных) стоит описание их совместимости.
Как видно, совместимость клиентов и серверов InterBase имеет 4 основных разновидности - полную, с ограничениями, с особыми свойствами и неустойчивую.
Полная совместимость возможна в ситуации, когда клиент и сервер имеют одинаковые версии или когда версия клиента старше версии сервера. Полная совместимость означает, что клиент может реализовать всю функциональность, предлагаемую сервером.
Совместимость с ограничениями означает, что, хотя сервер и предлагает большую функциональность, чем может поддержать клиент, их взаимодействие все же вероятно - в рамках тех возможностей, которые поддерживает клиент.
Неустойчивая совместимость означает, что взаимодействие слишком "старого" клиента и сервера возможно, но в ряде случаев такое взаимодействие может привести к ошибкам сервера или клиента, а также к порче данных. Такое сочетание клиента и сервера использовать не рекомендуется.
Совместимость с особыми свойствами возникает, когда клиенты версии 5.x связываются с базами данных, работающими под управлением InterBase-сервера версии 6.x. Причем тот факт, имеет ли база данных диалект 1 или диалект 3, имеет большое значение.
Если клиент от версии 5.x соединяется с базой данных 6.x, имеющей диалект 1, то он получает возможность работать с этой базой так, как будто она находится под управлением InterBase-сервера 5.x. Это означает (помимо невозможности использовать новые свойства InterBase 6.x), что, если в переведенной из-под 5.x базе данных есть объекты, название которых совпадает с каким-либо новым ключевым словом InterBase 6.x, клиенты 5.x по-прежнему будут иметь возможность работать с этой базой данных, используя ключевые слова в качестве идентификаторов. Но только для доступа к уже существующим объектам. Создание новых объектов, использующих в качестве идентификаторов ключевые слова. невозможно ни в клиентах 5.x, ни в клиентах 6.x.
Вот список новых ключевых слов, появившихся в InterBase 6.x:
COLUMN, CURRENT_DATE, CURRENT_TIME, CURRENT_TIMESTAMP, DAY, EXTRACT, HOUR, MINUTE, MONTH, SECOND, TIME, TIMESTAMP, TYPE. WEEKDAY, YEAR, YEARDAY.
Клиенты InterBase 5.x, подсоединяющиеся к базе данных 6.x, которая имеет диалект 3, имеют следующие ограничения:
* отсутствие доступа к полям, имеющие новые типы данных, определенные в 3-м диалекте InterBase 6.x;
* отсутствие доступа к идентификаторам, заключенным в кавычки;
* поля, имеющие тип DATE, рассматриваются клиентами 5.x как тип TIMESTAMP, т. к. в 4.x и 5.x тип "дата+время" назывался DATE.
Клиенты, применяющие для доступа к базе данных BDE версии ниже 5.3, не могут использовать объекты, имеющие новые типы данных, появившихся в 3-м диалекте InterBase 6.x.
Подводя итог разделу о совместимости клиентов и серверов, необходимо добавить, что, несмотря на возможность использовать "старых" клиентов, лучше всего использовать клиентов той же версии, которую имеют и серверы. Причем желательно, чтобы это соответствие было точным - вплоть до номеров билдов. То есть если вы используете в качестве сервера какой-нибудь клон InterBase. например Fuebnd 1 0, то желательно использовать и клиента именно от этой версии, а не от InterBase 6.0.1, например.
Перевод базы данных InterBase 6.x на 3-й диалект
Итак, мы подходим к рассмотрению вопроса о переводе баз данных InterBase 6 1-го диалекта на диалект 3, использующий все возможности версии 6.x. Начнем рассматривать этот перевод с предположения, что в качестве исходного материала мы имеем базу данных InterBase 6.x диалекта 1 и клиентские приложения, использующие синтаксис 1-го диалекта.
Сейчас речь идет именно о переводе базы данных в 3-й диалект. Дело в том, что клиентские приложения при подключении к базе данных также указывают диалект. После рассмотрения перевода базы данных мы рассмотрим и те шаги, которые нужны для миграции приложения на 3-й диалект.
Итак, что же мешает нам перевести нашу базу данных в 3-й диалект? Существует 4 основных препятствия, которые надо преодолеть, чтобы успешно перейти на 3-й диалект, - это двойные кавычки, ключевые слова, новые типы данных DATE и большие целые числа.
Двойные кавычки
Если в версиях InterBase 4.x и 5.x и диалекте 1 версии 6.x строковые константы позволялось описывать как с помощью как одинарных, так и двойных кавычек, то в 3-м диалекте двойные кавычки применяются только для обозначения идентификаторов, а одинарные - для строковых констант. Чтобы базу можно было перевести из 1-го диалекта в 3-й, необходимо заменить все двойные кавычки, ограничивающие строковые константы, на одинарные. Двойные кавычки могут находиться в триггерах, хранимых процедурах, представлениях, доменах, ограничениях и в значениях столбцов по умолчанию.
Ключевые слова
Новые ключевые слова могли быть использованы в базе данных, созданной в InterBase 4.x или 5.x, в качестве идентификаторов каких-либо объектов. Для перехода к диалекту 3 необходимо переименовать эти объекты, например YEAR -> YEAR 1 или YEAR->"year" (в 3-м диалекте ключевые слова могут быть идентификаторами, если они заключены в двойные кавычки) При смене диалекта базы данных лучше не использовать кавычки для разрешения конфликтов с ключевыми словами: разработчику надо привыкнуть к такому стилю работы и запомнить, что "Year", "YEAR" и "year" - разные идентификаторы.
Типы данных для работы с датой и временем
В версиях 4.x и 5.x и 1-м диалекте 6.x присутствует только один тип данных - DATE, который позволяет хранить информацию о дате и времени суток. В 3-м диалекте существует 3 типа для работы с датой и временем - это тип TMESTAMP, хранящий информацию о дате и времени (т. е он аналогичен типу DATE в 1-м диалекте и в 5.x), тип DATE, хранящий информацию только о дате, и тип TIME, хранящий информацию только о времени. Довольно запутанно, не так ли? Функции "старого доброго" DATE теперь берет на себя TIMESTAMP, a DATE, изменив свое назначение, означает теперь только дату.
Как же происходит замена типов данных? Объявления столбцов типа DATE автоматически меняют свой тип на TIMESTAMP уже при переходе на диалект 1 InterBase 6x, а вот с переменными типа DATE, использующимися (может быть) в триггерах и процедурах, ситуация сложнее. Они не меняют свой тип автоматически, и необходимо будет сменить их тип ("старый" DATE) на TIMESTAMP перед сменой диалекта 1 на 3.
Большие целые типы
В 3-м диалекте целые числа, имеющие тип NUMERIC или DECIMAL и разрядность больше девяти, хранятся в виде INT64, а менее девяти - в виде DOUBLE PRECISION. В 1-м диалекте и старых версиях все большие целые числа хранятся как DOUBLE PRECISION.
Обратите внимание, что INT64 - это обозначение механизма хранения больших целых чисел, а не какой-то конкретный тип
При переходе с 1-го диалекта на 3-й НИЧЕГО не изменится в хранении больших целых чисел, созданных ДО перехода на 3-й диалект, - они по- прежнему будут иметь тип DOUBLE PRECISION. Чтобы воспользоваться преимуществами хранения данных в INT64 (подробности см. в главе "Типы данных" (ч 1)). можно перенести данные в столбец с типом INT64 Для переноса нужно создать новый столбец нужной разрядности (например, NUMERIC(15,2)), который будет хранить свои значения в виде INT64, и перенести туда значения из старого столбца, затем старый столбец-источник удалить, а новый (со значениями в INT64) переименовать как старый. Переименование легко осуществить, воспользовавшись командой ALTER COLUMN, которая может сменить имя, тип и позицию столбца.
