Мир InterBase. Архитектура, администрирование и разработка приложений баз данных в InterBase/FireBird/Yaffil
Шрифт:
Вот такие препятствия ждут нас на пути к 3-му диалекту. Теперь от обзора перейдем к пошаговому алгоритму перевода базы данных от 1-го диалекта к 3-му. Мы будем рассматривать вариант, названный в [3, глава "Migration Guide"] способом "In-place migration", - когда база данных переводится на 3-й диалект без полного пересоздания базы данных и перекачки всех данных из старой базы данных в новую.
Пошаговые инструкции для перехода на 3-й диалект
Исходные данные: предположим, что мы переводим базу данных, состоящую из одного файла, - base2migrate.gdb. База данных - источник имеет 1 диалект. Резервная копия базы данных-источника сделана.
Итак, начнем.
* Необходимо
* Необходимо создать пустой файл с именем вроде makelt.sql, в который будут заноситься команды изменения метаданных базы данных, которые получим на основе анализа файла baseSource.ddl на предмет несоответствия содержащихся там метаданных требованиям диалекта 3. Команды изменения из файла makelt.sql подготовят базу данных-источник к переходу. Дальнейшие шаги до перехода будут посвящены наполнению файла.
* Отыскиваем в файле baseSource.ddl все двойные кавычки и заменяем их на одинарные. Затем копируем все измененные выражения в файл makelt.sql. Например, если строка, ограниченная двойными кавычками, находится внутри триггера, то надо скопировать весь триггер с измененной строкой (и не за- о\дые предложение set term перед триггером!). Заметьте, что простым поиском/заменой кавычек здесь не обойтись, ведь двойные и одинарные кавычки могут быть и в середине, и в конце, и в начале строковых констант. Для замены следует воспользоваться следующими правилами, составленными на основе таблицы 2.1 в InterBase б Mignation Guide [3]:
Табл 4.8. Правила перевода строк с двойными кавычками
| Двойные кавычки внутри строки | |
| Строка без кавычек как она есть | In "peg" mode |
| Строка, заключенная в двойные кавычки (допускается правилами IВ5.х и 1-го диалекта) | "In ""peg"" mode" |
| Строка, заключенная в одинарные кавычки согласно требованиям правил диалекта 3 | 'In "peg" mode' |
| Одинарные кавычки внутри строки | |
| Строка без кавычек | O'Reilly |
| Строка, заключенная в двойные кавычки (допускается правилами IВ5.х и 1-го диалекта) | "O'Reilly" |
| Строка, заключенная в одинарные кавычки, согласно требованиям правил диалекта 3 | 'O"Reilly' |
* После разрешения вопросов с двойными кавычками необходимо разобраться в типах для работы с датой и временем. Во время перехода на диалект 1 все "старые" столбцы типа DATE заменились на T1MESTAMP. Однако переменные типа DATE, которые могли быть в триггерах и процедурах, автоматически не заменились на TIMESTAMP. Поэтому надо произвести в файле baseSource ddl поиск всех вхождений переменных типа DATE и сменить их тип на TIMESTAMP. Все предложения (триггеры, представления, хранимые процедуры и т. д.), затронутые изменениями, следует перенести в файл makelt.sql. А затем надо повторить такой же поиск и произвести замену DATE на TIMESTAMP в файле makelt.sql, ведь в этот файл уже попали несколько предложений, модифицированных для того, чтобы соответствовать правилам 3-го диалекта для работы с
* Теперь следует заняться ключевыми словами, которые могли быть использованы в базе данных версий 5.x. Необходимо в файле makelt.sql найти все предложения, содержащие ключевые слова и изменить их на неключевые обозначения. Возможно, что изменение наименований столбцов повлечет за собой необходимость удалить и пересоздать зависимые от них объекты. Для получения списка зависящих от каждого меняющегося столбца объектов можно воспользоваться инструментами, указанными в приложении "Инструменты администратора и разработчика InterBase". Если существуют зависимые объекты, то их придется сначала удалить, а потом создать вновь, но уже с правильными ссылками на измененные объекты. То есть если у вас было поле, названное YEAR, и вы сменили его имя на YEAR1, то во всех процедурах, представлениях, триггерах необходимо заменить YEAR на YEAR1. Для этого придется удалить все эти объекты из базы данных, затем исправить имя столбца и после этого пересоздать все зависимые объекты.
Вообще говоря, избавление от ключевых слов является наиболее трудоемкой процедурой из-занеобходимости отследить и пересоздать, зависимые объекты. Лучше всего работу по удалению ключевых слов из базы данных выполнить отдельно, а не в рамках того набора изменений, который формируется в файле makelt.sql.
После разрешения вопроса с ключевыми словами в файле makelt.sql ту же самую процедуру необходимо проделать в файле baseSource.ddl и, как и раньше, скопировать все измененные предложения в файл makelt.sql.
* Теперь необходимо превратить предложения, содержащиеся в файле makelt.sql, в команды DDL, которые приведут нашу базу данных в соответствие с правилами 3-го диалекта.
Для этого в файле makelt.sql надо заменить словосочетание CREATE TRIGGER на ALTER TRIIGER, CREATE DOMAIN - на ALTER DOMAIN. Затем перед каждой командой CREATE VIEW вставить DROP VIEW для создаваемого представления - сочетание DROP/CREATE используется из-за отсутствия для представлений команды ALTER. Проверьте, чтобы среди скопированных предложений не оказалось команд CREATE PROCEDURE, а были только ALTER PROCEDURE. Затем если в makelt.sql есть предложения ALTER TABLE, которые изменяют ограничения таблиц (CHECK), то модифицируйте предложения ALTER TABLE так, чтобы они сначала удаляли эти константы, а затем вновь создавали, но уже с одинарными кавычками. Вы можете заметить, что измененные из-за двойных кавычек предложения мог>т дублироваться в файле makelt.sql предложениями, имеющими переменные типа DATE, но это неопасно: повторное выполнение предложений по модификации не приведет к порче метаданных, хотя, возможно, приведет к возникновению ошибок вида "attempt to store duplicate value", которые сигнализируют о попытке повторного создания объекта.
* В начало файла makelt.sql поместите команду CONNECT, которая обеспечит подключение к модифицируемой базе данных - что-то вроде:
CONNECT 'C:\Database\base2migr.gdb' USER 'SYSDBA' PASSWORD 'masterkey';
* Запустите скрипт из файла makelt.sql с помощью isql или любого другого инструмента администрирования базы данных. Вполне возможно, что первый запуск этого файла приведет к появлению массы ошибок. Внимательно проанализируйте эти ошибки, внесите соответствующие изменения в makelt.sql и вновь запустите его на выполнение, только уже не на "использованной" базе данных.
– извлеките из backup новую, нетронутую базу данных и проверяйте скрипт на ней.
* Когда добьетесь удовлетворительного результата со скриптом в makelt.sql, необходимо явно установить 3-й диалект базы данных следующей командой:
gfix -sql_dialect 3 base2migr.gdb -user sysdba -password masterkey
Теперь вы получили базу данных 3-го диалекта. Конечно, ряд моментов остался нерассмотренным, поэтому в случае возникновения необходимости получить исчерпывающую информацию по переходу на 3-й диалект следует обратиться к [3, глава "Migration Guide"].