Репликация баз данных в ПО "Фрегат"
Материал из FrigatWiki
Содержание |
Репликация
Что такое репликация?
Репликация - функционал, позволяющий производить обмен данными между двумя базами данных "Фрегат" в форме пакетов. Данные могут при этом не только синхронизироваться, но и видоизменяться по выбранному сценарию. Как правило, используется при отсутствии надёжного канала связи между базами, либо для решения других задач.
Типичные варианты использования репликации
1.Магазин и главный офис
2.Отчетная база (бухгалтерская) и база оперативного учета.
3.База для снятия аналитических отчетов и база оперативного учета.
Настройки репликации
Настройки репликации включают в себя, как правило, два этапа:
- подготовка базы к репликации со своей копией(в случае необходимости создание пустой базы)
- настройка сценария обмена между узлами
Объекты репликации
Название | Цифр.код | Буквенный код |
Валюта | 1 | CurrencyReference |
Прайс-листы | 2 | PriceLists |
Признаки товаров | 3 | GoodsGroups |
Группы товаров | 4 | GoodsGroups |
Товары | 5 | Goods |
Серии товара | 6 | GoodsSeries |
Организации | 7 | Faces |
Банковские реквизиты | 8 | BankInfo |
Склады | 9 | Stocks |
Аналитические признаки | 10 | Props |
Товары в инвентаризации | 18 | DocInvItems |
Товары по документам | 19 | DocItems |
Документы | 20 | Docs |
Система доступа | 100 | Access |
Количество по складам | 23 | Stocks_xQnts |
План счетов | 51 | BxAcnts |
Типовые операции | BxTopers |
Режим синхронизации для всех объектов
Настройки объектов определяют порядок и способы отправки и приема данных,
объектов конкретного типа. Они описываются в разделах "Параметры".
Некоторые настройки присущи всем объектам, а некоторые характерны
для конкретного объекта.
ОПЦИИ РАЗДЕЛА
insert_only=да
Данная настройка определяет режим приема данных, при котором происходит только
добавление новых объектов и не происходит их модификация (изменение их свойств).
resolve_mode=XX
Режим условной синхронизации объекта при приеме (по каким свойствам
осуществляется поиск объекта в принимающей базе данных). Свойства кодируются числом.
Значения для разных объектов обозначают разные свойства. Исключением является общее
для всех объектов значение=1, которое задает стандартный способ синхронизации,
при котором осуществляется поиск глобального идентификатора объекта в списке
принимающей базы, и при наличии такой записи определяется внутренний код объекта.
Если этот способ задан, то он имеет высший приоритет перед остальными способами.
Ниже приведена расшифровка значений для всех объектов репликации.
В случае, когда поиск осуществляется по нескольким параметрам, число XX получается
суммированием соответствующих значений отдельных настроек.
{ режимы условной синхронизации общий } 1 = определение по GUID 32768 = значение заставляет производить сравнение строковых параметров без учета регистра (8000h)
{ режимы условной синхронизации для Currency }
2 = название валюты
4 = текстовый код
8 = цифровой код
!по умолчанию resolve_mode=1+2+32768=32771
{ режимы условной синхронизации для PriceList }
2 = название прайс-листа
4 = код прайс-листа
!по умолчанию resolve_mode=1+2+32768=32771
{ режимы условной синхронизации для Stocks }
2 = название склада
!по умолчанию resolve_mode=1+2=3
{ режимы условной синхронизации для GoodsGroup }
2 = имя группы товаров
!по умолчанию resolve_mode=1+2+32768=32771
{ режимы условной синхронизации для Good }
2 = описание товара
4 = заголовок товара (только совместно с описанием)
8 = короткое имя
16 = артикул
32 = основной бар код
!по умолчанию resolve_mode=1+2=3
{ режимы условной синхронизации для GoodSeries }
2 = имя серии
4 = производитель
16 = название упаковки
32 = количество в упаковке(только совместно с название упаковки)
!по умолчанию resolve_mode=1+2+16+32=51
{ режимы условной синхронизации для Face }
2 = имя название организации
4 = форма собственности(только совместно с именем)
8 = короткое имя
16 = бар код
!по умолчанию resolve_mode=1+2=3
{ режимы условной синхронизации для Document }
2 - тип.дата.номер
4 - котрагент только совместно с предыдущей опцией
!по умолчанию resolve_mode=1
{ режимы условной синхронизации для План счетов }
2 - по коду счета
!по умолчанию resolve_mode=1+2=3
{ режимы условной синхронизации для типовых }
2 - по названию типовой
!по умолчанию resolve_mode=1+2=3
Специальные настройки объекта товар
Подготовка базы данных к репликации
ВНИМАНИЕ! ПЕРЕД НАЧАЛОМ ВЫПОЛНЕНИЯ НИЖЕСЛЕДУЮЩИХ ДЕЙСТВИЙ ВСЕ ПОЛЬЗОВАТЕЛИ, КРОМЕ ПОЛЬЗОВАТЕЛЯ, ОСУЩЕСТВЛЯЮЩЕГО ПРОЦЕСС ПОДГОТОВКИ БАЗЫ ДАННЫХ К РЕПЛИКАЦИИ, ДОЛЖНЫ ВЫЙТИ ИЗ ПРОГРАММЫ. ВСЕ НИЖЕПЕРЕЧИСЛЕННЫЕ ДЕЙСТВИЯ ДОЛЖНЫ ВЫПОЛНЯТЬСЯ ПОЛЬЗОВАТЕЛЕМ ПРОГРАММЫ ФРЕГАТ ПОД УЧЁТНОЙ ЗАПИСЬЮ SYSDВA. ОБЯЗАТЕЛЬНО ПЕРЕД ЗАПУСКОМ МОДУЛЯ ПОДГОТОВКИ К РЕПЛИКАЦИИ В КОПИЮ ПРОИЗВЕСТИ ДЕФРАГМЕНТАЦИЮ БАЗЫ ДАННЫХ.
(Как произвести дефрагментацию базы данных - смотрите в разделе Руководство по работе с ПО "Фрегат-Консоль").
Порядок действий по разделению базы данных на несколько баз
- Запустить программу Фрегат.
- В программе Фрегат запустить команду
Главное Меню - Службы - Модули - Модуль подготовки базы данных для репликации в копию. - После окончания работы модуля выйти из программы и после этого скопировать файл базы данных(БД).
- Подключить скопированный файл БД через Фрегат Консоль.
- В меню ПУСК - ПРОГРАММЫ - ФРЕГАТ - ИНСТРУМЕНТЫ запустить IBX SQL.
- В IBX SQL подключить скопированный файл БД.
- В IBX SQL набрать команду: update sys$info set ip='9-ти значное число'
(Например: update sys$info set ip='123456789')
Выполнить её, нажав молнию на панели инструментов.
Подтвердить транзакцию, нажав вторую кнопку справа на панели инструментов.
Зайти во Фрегат, подключиться к скопированной базе данных.
В Фрегате Главное Меню - Службы - Обмен_Данными, код узла должен быть тот, который установлен командой update sys$info set ip='9-ти значное число'. - В каждой из БД создать по узлу. В качестве кода при создании узла указывать код того узла, которому предназначается пакет. В разделе Что передавать указать то, что необходимо передавать.
- В меню ПУСК - ПРОГРАММЫ - ФРЕГАТ - ИНСТРУМЕНТЫ запустить IBX SQL.
- В IBX SQL подключить скопированный файл БД.
- В IBX SQL набрать команду: update xchgnodes set send_time='сегоднящняя дата'
(Например: update xchgnodes set send_time='19.01.2005 или update xchgnodes set send_time=’now’)
Дата(число,месяц,год) в обеих базах должна быть одинаковой!!!.
Выполнить её, нажав молнию на панели инструментов.
Подтвердить транзакцию, нажав вторую кнопку справа на панели инструментов.
Для контроля, что всё прошло успешно, выполнить запрос:
SELECT send_time FROM XCHGNODES
и в результате выполнения посмотреть поле send_time - там должна стоять дата, которая была указана в send_time='сегодняшняя дата'. - В IBX SQL отключить скопированный файл БД.
- В IBX SQL подключить исходный файл БД.
- В IBX SQL набрать команду: update xchgnodes set send_time='сегоднящняя дата'
(Например: update xchgnodes set send_time='19.01.2005' 2005 или update xchgnodes set send_time=’now’)
Дата (число,месяц,год) в обеих базах должна быть одинаковой!!!
Выполнить её.
Подтвердить транзакцию.
Для контроля, что всё прошло успешно, выполнить запрос:
SELECT send_time FROM XCHGNODES
и в результате выполнения посмотреть поле send_time - там должна стоять дата, которая была указана в команде update xchgnodes send_time='сегодняшняя дата'.
Базы данных готовы к обмену данными.
Проверка
- Выйти из программы Фрегат.
- Скопировать полученные базы данных и на этих копиях произвести следующие действия:
- Для проверки создать накладные в каждой базе.
- Обменяться пакетами.
После обмена пакетами накладные, созданные в каждой из БД, должны присутствовать в обеих базах.
Если накладные появились, базы готовы к работе. Копии баз данных, созданные ранее, можно удалить.
Известные проблемы, возникающие при репликации и в результате ее выполнения
Ситуация с задвоением товара.
Примечание. Возникает, если сценарий репликации не стандартный, а написан самостоятельно.
Когда товар или документ передаётся по репликации, то ему в момент передачи присваивается уникальный идентификатор, называемый GUID. Если эти GUID отличаются в двух базах, то происходит задвоение товаров и документов. В результате в базе-приёмнике есть два абсолютно одинаковых товара, у которых одинаково всё, кроме поля ID. Каждый товар имеет свою товарную историю.
Предпосылки возникновения такой ситуации:
- Неуникальность товара по имени (например, товары уникальны по артикулу, а называются одинаково)
- База-приёмник сделана с копии Базы-источника путем репликации - заведен GUID на товар в базе-приёмнике, и при передаче из источника на этот товар генерируется НОВЫЙ УНИКАЛЬНЫЙ GUID
Ошибки и проблемы после обновления версии
При обновлении версии могут появиться проблемы в репликации. Не отгружаются кассовые накладные и возвраты по кассе. Это связано с тем, что в старых версиях была возможность не выставлять контрагента при продажах по кассе. В новых версиях требуется обязательное наличие контрагента. Соответственно подобная проблема реплицируется на другие базы данных.
Перед исправлением необходимо выяснить ID типа документа (вывести колонку ID в типах документа). Например для кассовых накладных ID=45201.
Для исправления контрагента требуется прогнать скрипт по базе:
1. Открываете IBX ISQL (Пуск>программы>\Фрегат Корпорация 4\Инструменты\),
если программа выдает запрос на файл настроек, то нужно навести на файл C:\Program Files\F-Soft\SW4\sw.ini
2. Подключаете БД (Файл>подключение к базе данных>выбираете путь к Вашей БД скорее всего это C:\Program Files\F-Soft\DATA4\<имя базы данных>.gdb).
3. Копируете этот текст в верхнюю часть в белое поле программы:
для продаж по кассам:
update docs set face_id = (select id from faces where name = 'Розничный покупатель') where docs.dociden = 45201
4. Нажимаете SQL > выполнить.
для возвраты по кассам:
update docs set face_id = (select id from faces where name = 'Розничный покупатель') where docs.dociden = 45101
4. Нажимаете SQL > выполнить.
5. Нажимаете SQL > подтвердить транзакцию.