Подскажите пожалуйста надо в плане обмена РБД в событии ПриПолученииДанныхОтПодчиненного написать так что бы объект загрузился и пометился как измененный для отправки назад в подчиненный узел.

Уже по всякому делал. Но смог добиться только одного:

1. объект либо помечается для отправки назад (но при этом не загружается, и в подчиненный узел выгружается удаление объекта):

ПланыОбмена.ЗарегистрироватьИзменения(Ссылка,ЭлементДанных);


2. либо загружается но не отмечается для отправки подчиненному.
(тут различные варианты дают такой эфект)

Пробовал даже так:

ЭлементДанных.Записать();
ПланыОбмена.ЗарегистрироватьИзменения(Ссылка,ЭлементДанных);
ОтправкаНазад = Истина;

Все равно не регестрируются изменения.


Заранее за любые предложения (даже самые бредовые) огромное СПАСИБО!!!

.Записать() ?

(1) НЕТ!

(0) а вы не думаете, что у вас возникнет коллизия - когда объект будет изменен(зарегистрирован) в обоих обменивающих базах одновременно?

(3) не возникнет. мне его надо пометить для выгрузки а потом при выгрузке удалить в подчиненном узле. Эту то часть я написал без труда.

(1) не работает.

ничо не понял. Сейчас надо "мне его надо пометить для выгрузки а потом при выгрузке удалить в подчиненном узле"?

Есть такая хрень как
ЗарегистрироватьИзменения(Узел, Новый УдалениеОбъекта(Ссылка));

жесть какая-то..

(5) и не сработает. у вашего объекта ОбменДанными.Загрузка = Истина, ставьте в ложь.

но идея оч странная

просто обработкой это сделать, а не в процессе обмена, вся логика нарушается.
Зарегистрировал что надо - обменялся

(7) ЭлементДанных - это не обязательно ссылка. Это можеть быть и регистр.

(10) Нет, удаленеи есть только у ссылочных объектов, у регистров - запись пустого набора

В общем идея такая. Что бы подчиненный узел сделать поменьше удаляем там движения по не нужных регистров. Для этого решил сделать следующим образом:

1. Документ и регистр участвуют в обмене.
2. В ПриОтправкеДанныхПодчиненному для регистра делаю ОтправкаЭлемента = ОтправкаЭлементаДанных.Удалить
3. Документ может создаваться в подчиненном узле и проводится по этому регистру.
4. При загрузке в главном узле надо записи регистра загрузить и пометить для выгрузке. Тогда при выгрузке будет отправлен пустой набор записей и в подчиненном узле регистр очиститься.

Но загвоздка в последнем пункте.

На самом деле схема сложнее. Могут быть не только регистры но и другие элементы.

(12) мде.. а не проще управлять регистрацией движений регистров?
отключить авторегистрацию, создать подписку, в которой регистрировать нужные записи?

(13) да это понятно. так и сделано. Но есть объекты (движения регистров например), которые создаются в подчиненном узле, но они там не нужны. Поэтому хотел при загрузке в главный узел пометить эти объекты как измененные и при отправке выгрузить удаление объекта.

о ф и г е т ь

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

вот у вас примерно так же

(12) не надо играть процедурами ПриОтправкеДанныхПодчиненному и т.д. не по назначению.
Отключаем от Обменов, Чистим Поджчинённую, включаем обратно

(15) не понимаю сарказма. Эти объекты вполне нужны в главном узле.

(16) конечно вариант чистить подчиненную базу раз в месяц не плох, но отправлять удаление при загрузке все таки лучше. Да и быстрее. При чистке придется скорее всего надолго останавливать работу, а так бы удалялось по чуть чуть.

(17) ничо не понял, откуда чистка раз в месяц? Не надо отправлять ненужные данные в поджчинённую, но это никак не саязана с процедурами ПриОтправкеДанныхПодчиненному и отправке именно Удаления

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

(18) еще раз для тех кто не понял: не нужные данные создаются в подчиненном узле.

(19) например регистр взаиморасчетов.

В подчиненном узле ведеться только складской учет. Но есть документы, которые двигают взаиморасчеты. Но взаиморасчеты там не нужны. Если их не удалять то итоги в ноль не выходят и может произойти маленький коллапс.

Конечно для такой базы можно написать свою конфу и настроить обмен по другому. Но слишком сложно. Легче РИБом разрулить.

Я бы не стал извращать логику РИБа, сделай в подчинённой регламентое задание по регулярной очистке "типа ненужных" данных, или гони туда данные чтоб "регистр закрывался". я против, это моё имхо

(20)а корректность взаиморасчетов например при таком подходе (постоянное удаление промежуточных данных) точно сохранится?

СП:
ПланОбменаОбъект.<Имя плана обмена>.ПриПолученииДанныхОтПодчиненного (ExchangePlanObject.<Имя плана обмена>.OnReceiveDataFromSlave)
ПланОбменаОбъект.<Имя плана обмена> (ExchangePlanObject.<Имя плана обмена>)
ПриПолученииДанныхОтПодчиненного (OnReceiveDataFromSlave)
Синтаксис:

ПриПолученииДанныхОтПодчиненного(<ЭлементДанных>, <ПолучениеЭлемента>, <ОтправкаНазад>)
Параметры:

<ЭлементДанных>

При вызове обработчика события данный параметр содержит элемент данных, прочитанный из сообщения обмена данными. Элементами данных могут быть КонстантаМенеджерЗначения.<Имя константы>, объекты базы данных, наборы записей регистров, последовательностей или перерасчетов.
<ПолучениеЭлемента>

Тип: ПолучениеЭлементаДанных. Значение данного параметра может быть переприсвоено в обработчике. Оно определяет, будет ли прочитанный элемент данных записан в базу данных или нет.
При вызове обработчика параметр имеет значение Авто, что означает действия по умолчанию, то есть элемент данных будет принят, если не зарегистрировано изменений элемента данных для починенного узла, от которого получено сообщение обмена данными, или проигнорирован, если изменения зарегистрированы.
Значение параметра Принять означает, что прочитанный элемент данных должен быть принят, то есть записан в базу данных и, если были зарегистрированы изменения элемента данных для узла, от которого получено сообщение, то эта регистрация будет отменена.
Значение параметра Игнорировать означает, что прочитанный элемент данных должен быть проигнорирован, то есть запись его в базу данных не производится и никаких изменений в регистрацию изменений не вносится.
Значение по умолчанию: Авто
<ОтправкаНазад>

Тип: Булево. При вызове обработчика данный параметр имеет значение Ложь, что означает, что никаких действий предпринято не будет. Если же обработчик присвоит параметру значение Истина, то это означает, что состояние элемента данных в этом узле распределенной информационной базы должно быть передано узлу-отправителю обрабатываемого сообщения. Таким образом, если изменения элемента данных для узла-отправителя уже зарегистрированы, то никаких действий не производится, а если не зарегистрированы, то производится регистрация изменений.
Значение по умолчанию: Ложь
Описание:

Обмен изменениями данных и конфигурации в распределенной информационной базы производится с помощью сообщений обмена данными. Различаются сообщения, с помощью которых производится передача изменений от главного узла подчиненному и от подчиненного главному. Обработчик данного события вызывается после считывания элемента данных из сообщения, полученного от подчиненного узла и перед записью элемента в базу данных. Обработчик вызывается для каждого элемента данных, прочитанного из сообщения.
---
выставить Принять и Отправка назад принудительно поможет?
---
как вариант в "при отправке подчиненному" - ставить "удалять" в отправке элемента, если этот блок останется

(23) выставить Принять и Отправка назад принудительно поможет?
Не помогает.

"Значение параметра Принять означает, что прочитанный элемент данных должен быть принят, то есть записан в базу данных и, если были зарегистрированы изменения элемента данных для узла, от которого получено сообщение, то эта регистрация будет отменена."

(22) вариант конечно. если ни чего не найду то пожалуй так и сделаю.

Есть еще вариант запариться со вспомогательным планом обмена. Регистрировать там те объекты которые надо удалить. Но тоже сложно, и количество таблиц в базе вырастет, тоже не хотелось бы.

(24)а записать()+отправка назад?

кстати а просто отключить использование Итогов у нужных регистров не вариант?

(26) не регистрирует.

все-таки я за то, чтобы сохранять все данные в ПБ. Накроется вдруг ваша ЦБ, а в периферийных узлах нет данных

(27) в принципе тоже вариант. Правда я хотел такимже образом не только регистры но и всякие другие объекты регулировать.

(29) архивы делаются. просто базы реально большие.

(30) анализ размера таблиц проводился? С этого надо начинать обычно при поиске "толстых" мест

(31) например два регистра бухгалтерии по 15 млн записей. продажи 37 млн. Так что дофига. Не ларек.

(32) надо размер таблиц именно, бывает что таблицы итогов занимают больше чем сами данные в случае как раз "незакрывающихся" - тут отключить итоги. В другом месте может реально данных много - тут подумать о удалении

я помнится делал что-то похожее..

если с ЦБ приходило удаление объекта - искал все ссылки на объект, и если ссылки находились - регистрировал объект обратно в ЦБ.
Вроде проблем с регистрацей никаких не было

(34) это я тоже делал. тут загружать не надо. Мне надо одновременно и загрузить и отправить назад.

Ладно всем спасибо. Буду городить огород через задний проход.

опишись чтоле по результатам

Вот блин я лоханулся.

Сегодня со свежим взглядом пришел и все заработаело. В общем вот так работает:

ПолучениеЭлемента = ПолучениеЭлементаДанных.Игнорировать;
ПланыОбмена.ЗарегистрироватьИзменения(Ссылка,ЭлементДанных);
ЭлементДанных.Записать();

Это соответственно в ПриПолученииДанныхОтПодчиненного.