Я конечно понимаю что "велосипедостроение весьма занятная штука" , но может кому-то интересно...
Началось с того что постоянно возникают задачи типа:
1. выгрузить на сайт измененные позиции номенклатуры, контрагентов, статусы заказов.
2. выгрузить изменения из упр. базы в бухгалтерию.
3. собирать и отправлять н.р. раз в неделю статистику по измененным данным объектов определенного вида.
и т.д. и т.п.

Но самое здесь неприятное - это наличие УРБД.

На текущий момент есть кое-какие мысли как это может функционировать + есть немного наработок в виде работающего прототипа.

Как это выглядит сейчас:
1. база на скл (требование обязательно)
2. в базе 2 справочника: Планы обмена и подчиненный ему Настройки планов обмена. По первому думаю понятно, а второй хранит идентификаторы объектов метаданных, по которым нужно фиксировать изменения для данного плана обмена. Например: создаем план обмена "сайт" и для него указываем что нужно фиксировать изменения элементов справочника Номенклатура и Контрагенты.
3. ПриНачалеРаботыСистемы
  а) проверяется наличие таблицы в которую фиксируются идентификаторы измененных объектов, если такая не существует - она создается.
  б) проверяется, и если нужно - создается хранимка которая в таблицу из а) пишет изменение объекта
  в)на ВСЕ таблицы, которые могут контролироваться вешаются триггеры, проверяющие, если данная таблица включена хотя бы в один из ДЕЙСТВУЮЩИХ (активных в данный момент) планов обмена, то вызывается хранимка б), для фиксации изменеий в а).
   
4) есть несколько методов для: получения идентификаторов измененных объектов (за период, с момента последнего обмена и т.п.),  пометки записей как отработанных (н.р. получили изменения за вчерашний день, выгрузили их на сайт, и у себя пометили что они уже отработанные, чтобы в следующий раз повторно их же не брать).

Все это кое-как оформлено в виде класса.

Так вот. Если у кого-то есть заинтересованность в подобном, есть идеи как сделать инструмент удобнее, можно будет довести до ума вы выложить в общее пользование.

а потом какое-нить сохранение метаданных зашвырнет тебе весь справочник в выгрузку

Но идея не безнадежна.

---

Справочник-то ладно
А вот журнал документов - куда реальнее и куда страшнее.

leshik писал(а) 21. Октября 2012 :: 03:58:


Да, так и сделаю. Хочу причесать немного, и отвязаться от справочников. Чтобы просто был класс, чей вызов нужно было бы вставить в "при начале работы".

Цитата:


Через задницу:
перевести БД в режим обновления
обновиться
перевести БД в рабочий режим


Хотя... если при входе юзера в систему регать в какую-то табличку его SPID
Плюс при регистрации изменении тоже записывать SPID изменщика.
Тогда потом можно игнорировать все изменения, выполненные со СПИДом, не зафиксированным за пользователем.
Только нет никакой гарантии, что конфигуратор не получит СПИД, равный одному из предыдущих сеансов пользователя (при том, что по выходу пользователя надо будет фиксировать выход, "освобождая" СПИД - но и это не даст гарантии, ибо 1Ска временами имеет обыкновение падать на ровном месте).

(0) чем тригер плох ?

Точее надо сделать так.
ЦБ не для работы а только для обменов + тригер на ЦБ.

(5) "Хотя, стоп. тут другая "засада". При реструктуризации триггер скорее всего будет снесен" - кто мешает создавать триггер в глобальнике при начале работы системы, если такого триггера нет?

(11) Навскидку несколько вариантов:
- новая база,
- выгрузить - загрузить данные.
Во всех таких случаях определение триггера в глобальнике автоматом решает такие проблемы.

Z1 писал(а) 23. Октября 2012 :: 09:14:


Вот в случае _1СЖурн - что-то сомневаюсь. Ибо для нее точно создается таблица _1СЖурн_Нью и делается прочая хурма.
Создаются ли таблицы *_Нью для других объектов - просто не понмю. Скорее всего - да.

Лично я триггеры обновляю каждый раз при монопольном входе в систему + сделал так, чтоб после изменения конфигурации первый вход обязан был быть монопольным.