На практике возникают ситуации, когда не хватает стандартных режимов миграции.Данное решение предлагает бюджетное решение данной проблемы на примере Добавления ещё одного режима: «Место создания, центр и место назначения».
Режим: «Место создания, центр и место назначения».
Этот режим устанавливает поведение системы, при котором документ созданный в периферийной базе будет мигрировать обязательно в центр и в периферийную базу места назначения, если она отличается от места создания, а созданный в центральной базе будет мигрировать только в периферийную базу места назначения, если место назначения отлично от центральной базы.
Для реализации режима "Место создания, центр и место назначения" была выбрана стандартная конфигурация «Торговля и склад». Местом назначения миграции был выбран общий реквизит "Фирма". Хранение данных в центральной базе MS SQL.
Создадим центральную и две периферийных базы УРБД.
В созданной центральной базе свойства миграции «Все информационные базы». В режиме полной миграции все информационные базы полностью синхронизируются.
Для идентификации места назначения ИБ присвоим коды справочника «Фирмы» равными кодам наших центральной и периферийных баз
Теперь более подробно. Компонента УРБД для механизма обмена данных использует четыре таблицы:
1SSYSTEM(содержит общие настройки баз),
1SDBSET(хранит описание баз, участвующих в обмене),
1SDWNLDS (находятся сессии обмена данными),
1SUPDTS(содержатся объекты, которые были изменены).
Для наснаибольший интерес представляют две: 1SUPDTS(список измененных объектов), 1SDWNLDS(список сессий обмена данными).
Т.к. в свойствах миграции мы установили область миграции «Все информационные базы», то все изменения, которые мы будем делать в базах, будут отображаться в каждой из них.
Проиллюстрируем это на примере.
Для этого создадим, в центральной базе документ «Поступление ТМЦ Розница» указав фирму «Периферийная база №1» и посмотрим, какие изменения претерпела таблица 1SUPDTS. В таблице появились четыре записи: две для синхронизации с периферийной базой №1 (поле DBSIGN значение П1) и две для синхронизации с периферийной базой № 2 (поле DBSIGN значение П2). Заглянув с файл описания нашей БД (1Cv7.DDS), мы увидим, что идентификатор объекта 6532 (поле TYPEID соответствует объекту «Документ.ПоступлениеТМЦРозница», а идентификатор с номером 214 соответствует объекту «Справочник.Партии».Как мы видим в поле DBSIGN указывается база в которую будет мигрировать объект, поле TYPEID идентификатор типа объекта базы данных, OBJID –идентификатор самого объекта, поле DELETED используется для пометки физически удалённых объектов, а в поле DWNLDIN записывается идентификатор сессии обмена. Т.к. выгрузки ещё не было поле DWNLDIN пустое.
По условию нашей задачи справочники должны мигрировать во все информационные базы, а документы: место создания, центр и место назначения. Следовательно, если мы удалим из таблицы 1SUPDTS строку №4 (П2,6532,9ОЦБ), то при выгрузке в периферийную базу №2 документ «Поступление в розницу ТМЦ» №П100000001 не будет мигрировать, что нам и требуется.
А пока давайте продолжим исследование работы компоненты УРБД.
Теперь создадим документ «Поступление ТМЦ Розница» в периферийной базе, например, №1 и посмотрим, как там изменится таблица 1SUPDTS. Механизм работы в центральной базе отличается от механизма работы УРБД в периферийной базе. Появилось те же объект (Документ.ПоступлениеТМЦ, Справочник.Партии) две записи(т.к. Периферийные базы в формате DBF, то идентификаторы представлены в тридцатишестеричной системе), но только с пунктом назначения центральная база. Напрашивается вопрос: а как же объекты попадут в периферийную базу №2? Сделаем загрузку данных в центральную базу и посмотрим, что появится в таблице 1SUPDTS.(
Мы видим, что недостающие две записи для периферийной базы №2 сформировала центральная база.
Из этого следуют, что все манипуляции с удалением «лишних» записей таблицы 1SUPDTS достаточно делать на стороне центральной базы. Центральная база должна получать все документы.
Теперь давайте напишем запрос, который будет удалять ненужные записи из таблицы 1SUPDTS по условию нашей задачи. Т.к. справочники у нас мигрируют во всех базы, нам нужно удалять только документы, т.е. получить только идентификаторы типов объекта документ. Для решения этой задачи лучше всего взять таблицу 1SJOURN, которая хранит все документы системы и имеет поля IDDOCDEF (идентификатор типа объекты) IDDOC(идентификатор объекта).
Select U.DBSign, U.TypeID, U.ObjID
From _1SUPDTS U(NOLOCK) Join _1SJOURN J(NOLOCK)
On U.TypeID=J.IDDocDef And U.OBJID=J.IDDoc
Select U.DBSign, U.TypeID, U.ObjID
From _1SUPDTS U(NOLOCK) Join _1SJOURN J(NOLOCK)
On U.TypeID=J.IDDocDef And U.OBJID=J.IDDoc Join SC4014 S(NOLOCK) /*спр.Фирмы*/
On J.SP4056/*Общий реквизиты фирмы*/=S.ID
And U.DBSign<>S.Code /*выбрать объекты, в которых пункт назначения не равен реквизиту «Фирма» в документе*/
And U.DBSign<>Right(U.ObjID,3) /*выбрать объекты, в которых место их создания не совпадает с местом назначения*/
Delete _1SUPDTS
From _1SUPDTS T1 Join (
Select U.DBSign, U.TypeID, U.ObjID
From _1SUPDTS U(NOLOCK) Join _1SJOURN J(NOLOCK)
On U.TypeID=J.IDDocDef And U.OBJID=J.IDDoc Join SC4014 S(NOLOCK)
On J.SP4056=S.ID And U.DBSign<>S.Code And U.DBSign<>Right(U.ObjID,3)) T2
On T1.DBSign=T2.DBSign
And T1.TypeID=T2.TypeID
And T1.ObjID=T2.ObjID
CREATE TRIGGER [_1SDWNLDS_Delete] ON [dbo].[_1SDWNLDS]
FOR DELETE
AS
Set NoCount On
Delete _1SUPDTS
From _1SUPDTS T1 Join (
Select U.DBSign, U.TypeID, U.ObjID
From _1SUPDTS U(NOLOCK) Join _1SJOURN J(NOLOCK)
On U.TypeID=J.IDDocDef And U.OBJID=J.IDDoc Join SC4014 S(NOLOCK)
On J.SP4056=S.ID And U.DBSign<>S.Code And U.DBSign<>Right(U.ObjID,3)) T2
On T1.DBSign=T2.DBSign
And T1.TypeID=T2.TypeID
And T1.ObjID=T2.ObjID
Процедура ПриЗаписи()
Форма.Фирма.Доступность(0);
КонецПроцедуры // ПриЗаписи()
Процедура ПриОткрытии()
Форма.Фирма.Доступность(?(Выбран()=0,1,0));
КонецПроцедуры //ПриОткрытии()
Украинский 1С форум: всё про 1С 8.3, 1С 8.2, 1С 8.1, 1С 8.0, 1С 7.7
https://pro1c.org.ua