5.3.Дополнительные возможности репликации
При работе с утилитой репликации можно использовать ряд дополнительных возможностей, среди них:
Отправка SQL-скриптов.
Создание исполняемых файлов и анализ результатов репликации.
Управление изменением метаданных.
Пользовательское управление репликацией.
5.3.1.Отправка SQL-скриптов
Существует возможность отправлять не только данные по репликации, но и SQL-скрипты. Для этого SQL-скрипты следует добавить в таблицу «rep_ExecutedSQL» в поле «SQL».
Например,
insert into rep_ExecutedSQL(SQL)
values(‘alter table tbl_Plugin1 add Sale decimal(18,4) not null’)
При добавлении записи автоматически заполняется пароль для запуска этого скрипта на удаленной точке. Этот пароль берется из текущей точки (по умолчанию он пустой). Чтобы SQL-скрипт отработал при получении, необходимо выполнение условий:
Точка, которая прислала скрипт, должна быть в списке точек обмена на точке-приемнике (закладка [Точки обмена] утилиты «SetOffline»).
Пароль на выполнение SQL-скрипта должен совпадать с паролем, указанным при регистрации точек обмена на точке-приемнике (закладка [Точки обмена] утилиты «SetOffline) для точки, которая прислала скрипт (Рис. 5 .37).
Рис. 5.37 – Редактирование точки обмена
!
|
Если SQL-скрипты выполняют изменения рабочей базы (обновление версии Terrasoft CRM или любое другое изменение метаданных рабочей базы), то при получении такого пакета программа Terrasoft CRM должна быть закрыта.
Если же SQL-скрипты выполняют изменения схемы репликации, то при их получении необходимо закрыть утилиту «SetOffline.exe».
|
5.3.2.Создание исполняемых файлов репликации
Запуск процесса репликации можно осуществлять с помощью исполняемых файлов с расширениями <*.cmd> или <*.bat>. Их необходимо создать самостоятельно. При создании исполняемых файлов можно анализировать переменную %errorlevel%. Значения этой переменной могут быть следующими:
0 – были получены пакеты репликации, репликация прошла успешно;
100 – репликация завершилась с ошибкой;
101 – ошибка при отправке пакета;
102 – последний отправленный пакет репликации не был подтвержден;
201 – при проверке почты не было обнаружено пакетов репликации;
-1 – неизвестный код.
5.3.3.Управление изменением метаданных
Если при выполнении репликации разрешено изменение метаданных (создание таблиц, добавление полей и т.п.), следует в любой утилите, позволяющей отправлять SQL-запросы, (например, Query Analyzer) запустить хранимую процедуру «rep_PrepareTable».
Например,
exec [rep_PrepareTable] ‘tbl_Acount’,0
где первый параметр – имя таблицы, второй может принимать значения:
«0» (по умолчанию) означает добавление в схему репликации;
«1» - удаление.
5.3.3.1.Особенности подготовки таблицы к репликации
При подготовке таблицы к репликации ее физическая структура изменяется следующим образом:
Добавляются, если отсутствуют, служебные поля: «Build_id», «Branch_id», «TimeChange», «Editor_id», «Sender_id», «TimeReceive». В таблицах так же называть собственные поля нельзя.
Все поля, которые используются во внешних ключах, изменяют свое значение с «NOT NULL» на «NULL». Если это ограничение важно, то его необходимо реализовывать на уровне клиента.
Если таблица зависит от других таблиц, или от нее зависят другие таблицы, то это должно быть реализовано на уровне внешних ключей. Если внешний ключ отсутствует, то связь между таблицами не будет корректно реплицироваться.
Добавляются или пересоздаются (если существуют) два триггера для offline репликации:
«del_ + имя таблицы»;
«iu_ + имя таблицы».
Собственные триггеры с такими названиями создавать нельзя.
Если таблица отсутствовала в схеме репликации, то она добавляется в схему репликации с параметрами: «Отправлять все записи», «Принимать», «Добавлять», «Обновлять» и «Удалять все записи».
Обновляется информация о внешних ключах и составе полей в служебных таблицах «rep_Field», «rep_Constraints».
5.3.3.2.Добавление пользовательского поля
Для добавления пользовательского поля необходимо выполнить следующую последовательность действий:
Добавить пользовательское поле на сервере.
Выполнить скрипт по созданию поля физически.
Если поле является внешним ключом, то выполнить также скрипт по созданию внешнего ключа и индекса. Эти скрипты необходимо занести в таблицу «rep_ExecutedSQL».
Для включения поля и/или таблицы в схему репликации, необходимо запустить хранимую процедуру «rep_PrepareTable»:
exec [rep_PrepareTable] N'tbl_Account'
и занести скрипт в таблицу «tbl_ExecutedSQL» (см. пример ниже).
На точках обмена дополнительные действия выполнять не нужно, так как вся необходимая информация будет передана в процессе репликации.
Рассмотрим примеры добавления пользовательских полей.
Добавление простого поля типа «Строка» в раздел [Контрагенты].
Добавление поля:
if not exists(select * from information_schema.columns
where table_name = lower(N'tbl_Account')
and column_name = lower(N'Name2'))
begin
alter table [tbl_Account] add [Name2] nvarchar(250)
end
Занесение скрипта в таблицу «rep_ExecutedSQL»:
insert into [rep_ExecutedSQL] ([SQL])
select 'if not exists(select * from information_schema.columns
where table_name = lower(''tbl_Account'')
and column_name = lower(''Name2''))
begin
alter table [tbl_Account] add [Name2]
nvarchar(250)
end'
Добавление поля типа «Справочник» в раздел [Контрагенты].
Добавление поля:
if not exists(select * from information_schema.columns
where table_name = lower(N'tbl_Account')
and column_name = lower(N'Offering1ID'))
begin
alter table [tbl_Account] add [Offering1ID] uniqueidentifier
end
Занесение скрипта в таблицу «rep_ExecutedSQL» выполняется по аналогии с предыдущим примером.
Создание внешнего ключа:
if object_id(N'FAccount_Offering1ID') is null
begin
alter table [tbl_Account] add constraint [FAccount_Offering1ID]
foreign key ([Offering1ID]) references [tbl_Offering] ([ID])
end
Занесение скрипта в таблицу «rep_ExecutedSQL» выполняется по аналогии с предыдущим примером.
Создание индекса:
if not exists (select * from [sysindexes]
where [name] = N'IAccount_Offering1ID'
and [id] = object_id(N'tbl_Account'))
begin
create index [IAccount_Offering1ID] on [tbl_Account]([Offering1ID])
end
Занесение скрипта в таблицу «rep_ExecutedSQL» выполняется по аналогии с предыдущим примером.
5.3.4.Пользовательское управление репликацией
В случае необходимости можно добавлять свой код в ход репликации.
до отправки пакета – в хранимую процедуру «rep_BeforeInsert_database»
после отправки пакета – в хранимую процедуру «rep_AfterInsert_database»
до приема пакета – в хранимую процедуру «rep_BeforeSend_Message»
после приема пакета – в хранимую процедуру «rep_AfterSend_Message»
Например, необходимо выполнить собственные действия над принятыми данными (таблицы плагина):
alter procedure [rep_AfterSend_Message]
as
begin
update [cm_Table1]
set [Field1] = getdate(),
-- Обязательно для таблиц, участвующих в репликации
TimeChange = TimeChange,
Build_id = Build_id,
Editor_id = Editor_id,
Sender_id = Sender_id,
TimeReceive = TimeReceive
where [id] < 100
end        
|
