Задача
Вы делаете большой проект для удаленного заказчика. Пилотный вариант уже готов и отправлен заказчику, который заполняет базу данными, нажимает кнопочки, печатает отчеты и радуется, как же все здорово и автоматически работает.
По мере того, как заказчик все больше входит во вкус новой жизни, у него появляются новые потребности, хотелки и капризы. Удаленный доступ к его компьютеру зачастую просто отсутствует, и даже если он есть, не всегда удобен (плохой интернет, необходимость работать ночью из-за разных часовых поясов и т.п.). Поэтому вы спокойно реализуете запросы заказчика на своей копии базы и в какой-то момент решаете, что можно обновить его рабочую версию. Для этого вам нужны все записи всех таблиц, в которых пользователи могли изменить старые или завести новые данные. Следовательно, сначала нужно экспортировать все "пользовательские" данные из старой базы в промежуточные (транзитные) файлы, а затем из этих файлов импортировать все данные в соответствующие таблицы обновленной "пустой" версии БД.
Вроде бы ничего сложного, но на практике это требует множества "телодвижений" и соблюдения простых, но очень важных условий. Формирование полной выборки, отбор нужных таблиц и полей для экспорта/импорта, правильное согласавание полей при импорте, пересчет полей-счетчиков и др. Можно все это делать и вручную, но при большом количестве таблиц такая работа становится нудной, требующей повышенной аккуратности и чреватой фатальными ошибками - потеря связей между таблицами, задублированность счетчиков и просто "каша" в данных.
Попробуем сделать эту процедуру простой, надежной и хотя бы частично ее автоматизировать...
Решение
Допустим, что в вашей БД, состоящей из одного файла, есть три обновляемые пользователем таблицы - Группы, Товары и Baza (таблица из одной записи, содержащей поля - значения по умолчанию).
До того, как вы отправите заказчику первую рабочую версию БД, в ней уже должны быть созданы скрипты:
1.Скрипт "Найти ВСЕ записи во ВСЕХ обновляемых таблицах" (а проще - для универсальности - вообще во всех)
Далее желтым цветом выделяются группы скрипт-степов, которые должны повторяться для каждой обновляемой таблицы.
2. Скрипт "Экспорт", начинающийся с создания папки \Backup внутри папки с вашей БД и выполнения скрипта "Найти ВСЕ записи...",
в котором для каждой таблицы X, в которой могут быть пользовательские изменения, должна быть группа скрипт-степов вида:
GotoLayout(TableNameX) ---- переход в лэйаут, основанный на TableХ;
Export Records(файл:"TableХ.fmp12";specify) - экспорт в файл TableX.fmp12, набор полей - ВСЕ невычисляемые включая Global, т.е. все типы, кроме Calculation и Summary. Можно в путь добавить имя папки, например, file:../Backup/TableХ.fmp12.
Подробнее о том, как правильно и без головной боли сформировать список экспортируемых полей, см. в приложенном демо-файле.
3. Скрипт "Удалить ВСЕ записи во ВСЕХ обновляемых таблицах"
4. Скрипт "Импорт", начинащийся со скриптов "Найти ВСЕ записи..." и "Удалить ВСЕ записи...",
в котором для каждой таблицы X, в которой могут быть пользовательские изменения, должна быть группа скрипт-степов вида:
GotoLayout(TableNameX) ---- переход в лэйаут, основанный на TableХ;
Import Records(файл: "TableХ.fmp12";Specify) ---- импорт из файла TableX.fmp12,
порядок импорта - обязательно MATCHING;
галочка "Perform auto-enter..." - обязательно СНЯТА!
Путь - тот же: file:../Backup/TableХ.fmp12.
Если в таблице есть счетчик idX (auto-enter serial number), то добавляем еще 3 степа:
Sort --- сортировка по idX по возрастанию;
GoTo Record [Last] --- переход к последней записи;
Set Next Serial Value [idX; idX + 1] - выставляем правильное следующее значение счетчика.
Примечание. При появлении новых полей или таблиц сначала создайте и выполните скрипт "Экспорт", потом настраивайте импорт на уже существующий файл TableX.fmp12.
Что дальше?
А. Отдали базу пользователю. Он добавляет данные, а вы тем временем совершенствуете оригинал. Если вы не добавляете новых таблиц или хранимых полей и не меняете их названия/типы, а только добавляете/исправляете скрипты, вычисляемые поля, лэйауты или связи (ТО), то ничего в процедуре синхронизации менять не нужно. В противном случае вам нужно добавить соответствующие поля/таблицы/скрипт-степы в скриптах "Удалить ВСЕ...","Экспорт", "Импорт".
Б. Пришло время обновиться. Пользователь присылает вам архив своей базы и до получения обновленной копии ничего в своем экземпляре не делает. Обновление, если нет нестандартной ситуации, занимает несколько минут.
В. Вы открываете его файл (в отдельной папке), запускаете скрипт "Экспорт", в папке \Backup получаете набор файлов Table1.fmp12, Table2.fmp12, Table3.fmp12 и т.д.
Г. Закрываете его файл, копируете папку \Backup в свою рабочую папку с вашим обновленным файлом.
Д. Открываете ваш файл, запускаете скрипт "Импорт".
Е. Сравниваете контрольные цифры в исходной и конечной версиях.
Ж. Закрываете файл, архивируете и отправляете пользователю.
Он продолжает работать с ним как ни в чем ни бывало, а вы, имея его новые данные, продолжаете улучшать свое творение.
Далее см. пункт А.
Вариант (иногда предпочтительный): пользователь сам может делать "Экспорт" и отправлять вам только совсем "легкую" папку \Backup.
Схема надежна и безопасна, так как у всех всегда есть предыдущая версия (например, в почте).
Рекомендации
1. Все скрипты обновления должны выполняться с установленной опцией "Run script with full access priveleges".
2. Поначалу для полного контроля новые скрипт-степы "Export" и "Import" выполняйте с диалогом (галочка "Perform without Dialog" снята). Когда скрипты отлажены, от диалога можно отказаться.
3. После обновления сверяйте старую и обновленную версии по количеству записей в критичных таблицах, по контрольным итоговым суммам и т.п.
4. Если вы завели новые невычисляемые поля, предполагающие наличие значений по умолчанию, не забудьте перед отправкой новой версии клиенту заполнить ("отреплейсить") эти поля нужными значениями.
5. Не забудьте предупредить клиента, что до отправки ему обновленной версии в его рабочей базе не должны заводиться никакие новые данные. Если такое все-таки случилось, он должен вновь прислать последнюю рабочую копию.
Дополнительные пояснения и детали - в демо-файле.
Автор: FMLogia
Тэги: синхронизация версий БД