По материалам сайта Softpoint.ru/
Некоторое время назад мне нужно было решить задачу по настройке репликации транзакцией БД под 1С из одного сервера на другой. Как описывалось в предыдущих статьях, я снял все ограничения 1С по изменению структуры БД. Тем не менее, столкнулся с дополнительными проблемами. В основном, проблему можно сформулировать так , что при изменении структуры БД мастер репликации требует переформировании всей схемы БД, а не конкретно выбранного объекта. Также поставленные на репликацию таблицы нельзя никаким переименовывать, удалять, что 1С и делает при изменении структуры БД. То есть, конечно, можно было перед изменением структуры снимать все (можно конечно только измененные, но их нужно знать заранее) таблицы с репликации, а затем ставить заново, но эта операция требует гораздо большего времени (и сетевого трафика), чем изменение настройки репликации конкретного объекта.
Владимир Сердюк
Нужно было решить следующие проблемы:
1) Возможность изменения структуры реплицируемых объектов
2) Возможность определения измененных объектов до начала изменения структуры конфигурации 1С и после.
3) Изменение настройки правил репликации только для измененных объектов.
4) На издателе формировался триггер for update в котором не использовалась конструкция set nocount on.
Первая проблема решалась изменением служебных полей определяющих статус реплицируемой таблицы в sysobjects.
Вторая проблема решалась сохранением слепка sysobjects до изменений и сравнение его с sysobjects после изменений.
drop table copysysobjects
select * into copysysobjects from sysobjects where xtype='U' and status>0
--сохранение слепка до изменений
select id,name from sysobjects cso where cso.id not in (select id from copysysobjects)
and xtype='U'
and status>0
--определение измененных объектов
Третья проблема решалась с помощью использования хранимых процедур sp_dropsubscription, sp_droparticle,
для снятия объектов, определенными предыдущим скриптом, с репликации(с подписки и издателя соответственно). А также с помощью sp_addarticle, sp_addsubscription соответственно для постановки на репликацию. Нужно отметить также, что для
больших таблиц можно было бы пользоваться хранимыми процедурами по постановке не таблицы целиком на репликацию а только колонки.
Четвертая проблему можно решать несколькими способами. Один из них это изменение шаблона репликационного триггера. Второй это изменение триггеров дополнительным скриптом.(Хотя первый способ мне кажется более красивым и надежным)
declare @str char(8000)
declare @dropstr char(8000)
declare @trigger_name char(100)
declare Mylog cursor local fast_forward for
select rtrim(c.text),rtrim(o.name) from dbo.syscomments c, dbo.sysobjects o
where o.id = c.id
and o.name like '%sp_MSsync_upd_trig_%'
order by c.number, c.colid
open Mylog
fetch Mylog into @str,@trigger_name
while (@@fetch_status<>-1)
begin
set @dropstr='drop trigger '+rtrim(@trigger_name)
set @str=rtrim(replace(@str,' declare @rc int',' declare @rc int set nocount on'))
set @str=rtrim(@str)+'set nocount off'
select @str
exec(@dropstr)
exec(@str)
fetch Mylog into @str,@trigger_name
end
close Mylog
deallocate Mylog
P.S. У автора статьи на базе репликации транзакцией для 1С есть уже готовое, прошедшее внедрения, решение.
Для описанной выше задачи оказалось более эффективным решение не предполагающее изменение в структуре БД 1С. То есть измененный мастер репликации MSSQL вообще не вносит никаких изменений в структуру существующих таблиц.
Начать дискуссию