Заказы на доработку 1С (сервис удаленной работы)

Хранилище

База знаний
Бесплатные отчеты, обработки, конфигурации, внешние компоненты для 1С Статьи, описание работы, методики по работе с 1С

Здравствуйте, гость ( Вход | Зарегистрироваться )



> Расширение режимов миграции в УРБД 1С 7.7 SQL          
Vofka Подменю пользователя
сообщение 17.12.11, 12:54
Сообщение #1

У нас здесь своя атмосфера...
***********
Группа: Основатель
Сообщений: 13948
Из: Киев
Спасибо сказали: 4514 раз
Рейтинг: 3635.6

На практике возникают ситуации, когда не хватает стандартных режимов миграции.Данное решение предлагает бюджетное решение данной проблемы на примере Добавления ещё одного режима: «Место создания, центр и место назначения».

Режим: «Место создания, центр и место назначения».
Этот режим устанавливает поведение системы, при котором документ созданный в периферийной базе будет мигрировать обязательно в центр и в периферийную базу места назначения, если она отличается от места создания, а созданный в центральной базе будет мигрировать только в периферийную базу места назначения, если место назначения отлично от центральной базы.



Для реализации режима "Место создания, центр и место назначения" была выбрана стандартная конфигурация «Торговля и склад». Местом назначения миграции был выбран общий реквизит "Фирма". Хранение данных в центральной базе 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


Этот запрос выберет из системы все измененные документы, записанные в таблицу 1SUPDTS, дополним его нашими условиями:

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) /*выбрать объекты, в которых место их создания не совпадает с местом назначения*/


SQL-скрипт, который удаляет ненужные записи из таблицы 1SUPDTS:

         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


Для автоматического удаления ненужных записей в таблице 1SUPDTS нам нужно создать триггер. Вопрос только, на какое событие и в какой таблице его создавать. Можно, конечно, создать его для таблицы 1SUPDTS, но это не оптимально. Лучше всего использовать для этой цели таблицу, которая хранит сессии обмена (1SDWNLDS). Запустим Profiler и посмотрим, что происходит с этой таблицей при выгрузке и загрузке данных. При выгрузке компонента сначала заполняет таблицу 1SDWNLDS данными о новой сессии обмена, потом удаляет подтвержденные сессии обмена и только потом начинает анализировать таблицу 1SUPDTS и создавать файл переноса данных. При загрузке компонента делает всё в обратном порядке: сначала анализирует таблицу 1SUPDTS, регистрирует изменения в базе данных, а потом заполняет таблицу 1SDWNLDS и удаляет данные о подтвержденных сессиях обмена. Т.е. создав триггер для таблицы _1SDWNLDS, например, на удаление(добавление) мы можем при выгрузке очистить нашу таблицу 1SUPDTS непосредственно перед формированием файла обмена, а при загрузке, когда все изменения будет приняты в центральной базе, очистить таблицу 1SUPDTS, по условию «место назначения».

Окончательный SQL-скрипт будет выглядеть вот так:

            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


Возможные коллизии и их устранение:

1.Непосредственное удаление документов из базы

При непосредственном удалении документов из базы методом Удалить(1) запись о документе будет удалена из таблицы 1SJOURN и при выгрузке эти записи не будут удалены из таблицы 1SUPDTS, т.к. таблицы связаны внутренним объединением, и попадут во все информационные базы. Компонента абсолютно корректно обработает эти записи: попытается найти и удалить эти документы.



2.Изменение реквизита «Фирма» в документе.

При изменении реквизита «Фирма» в документе может возникнуть коллизия, если была сделана загрузка-выгрузка файлов обмен со старым значением реквизита «Фирма», т.е. система перенесёт документ в информационную базу со старым значением реквизита «Фирма», а затем, при очередной выгрузке-загрузке в информационную базу нового значения реквизита «Фирма» . Поэтому во всех документах, которые участвуют в обмене и в формах, и в которых есть возможность изменить реквизит «Фирма», нужно добавить код для предопределенных процедур ПриЗаписи(), ПриОткрытии():

Процедура ПриЗаписи()

     Форма.Фирма.Доступность(0);

КонецПроцедуры // ПриЗаписи()



Процедура ПриОткрытии()

     Форма.Фирма.Доступность(?(Выбран()=0,1,0));

КонецПроцедуры //ПриОткрытии()


На этом все.

[необходимо зарегистрироваться для просмотра ссылки]

Не нашли ответа на свой вопрос?
Зарегистрируйтесь и задайте новый вопрос.


Ответить Новая тема
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 

RSS Текстовая версия Сейчас: 28.03.24, 20:48
1С Предприятие 8.3, 1С Предприятие 8.2, 1С Предприятие 8.1, 1С Предприятие 8.0, 1С Предприятие 7.7, Литература 1С, Общие вопросы по администрированию 1С, Методическая поддержка 1С - всё в одном месте: на Украинском 1С форуме!