Подписка на событие регистра ПередЗаписью и ПриЗаписи #771580

Есть независимый регистр сведений, периодический. Если делается запись через МенеджерЗаписи, то вначале происходит удаление, потом вставка. Если через набор записей, то удаления (т.е. срабатывания ПередЗаписью с нулевым количеством) нет. Когда используем менеджер, запись всегда одна, и в первое срабатывание ПередЗаписью она из таблицы удаляется. Когда используем набор, передЗаписью срабатывает один раз и старые записи в таблице есть. Задача - универсальный код для подписки (вызванной как посредством менеджера, так и набора), использующий "старые" записи в ПриЗаписи. Где-то на форуме мне попадалось решение с использованием временной таблицы для передачи удаляемых записей. Если не трудно, покажите ссылку.

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

ЭтотОбъект.ДополнительныеСвойства.Вставить("СтарыйНабор", ДанныеКоторыеХочешьПередаватьМеждуСобытиямиИПодписками)

ЭтотОбъект.ДополнительныеСвойства.СтарыйНабор или Если не ЭтотОбъект.ДополнительныеСвойства.Свойство("СтарыйНабор", СтарыйНабор) Тогда    ВызватьИсключение "Сектор 'Б' на барабане, вы - банкрот, всё у вас сгорело к четовой матери!";

Спасибо за ответ! Но в подписке нет переменной ЭтотОбъект, а есть Источник. И в случае первого прогона ПередЗаписью источник один, а при втором прогоне совершенно другой. Это было в первую очередь проверено, задолго до написания вопроса. Или же я чего-то в ответе не поняла.

Т.е. источник меняется, и допсвойство не видно.

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

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

ну вы передаете данные через ДополнительныеСвойства внутри одного прогона. Между ПередЗаписью и ПриЗаписи. Зачем вы второй прогон сюда?

В том-то и дело, что я их хочу передать во второй прогон, если он есть. Т.к. если прогонов было 2, старых данных на втором прогоне в таблице нет. А если один (всего один и второго не будет), старые данные есть. Транзакция заканчивается после второго прогона в общем случае. В приЗаписи мне нужно каким-то способом определить, какой по счету прогон - второй или первый. Если он второй, старые данные брать из временной таблицы. А то получается, что иначе работа алгоритма должна зависеть от того, при помощи какого объекта был создан набор записей.

вот жешь беда-то необоримая...

это происходит пир любой записи в регистр

короче, автор, ты сруйню затеял. Зачем тебе это все? Людскими словами можешь объяснить - для чего ветка?

Чтобы при окончании транзакции из двух прогонов в окончательном ПриЗаписи получить старые данные.

Видела раньше ветку, где решалась аналогичная задача. Сейчас не могу найти. Хотелось бы посмотреть, может в ней решение удачней моего с экспортной переменной для менеджера временных таблиц.

не получишь. Живи с этим

Даже если передЗАписью делать запрос к регистру по значениям отбора из Источника, пхать это в ДополнительныеСвойства, то при втором вызове ПередЗаписью источник будет уже другой и там ни чего в допсвойствах не будет. Если - во временное хранилище только разве, но открытым и нерешаемым остается вопрос, как во втором вызове обработчика угадать ИД записи во временном хранилище.

Уже недели 2 работает вариант с помещением в ТЗ, а её в параметр сеанса. Есть намерение сделать через временную таблицу (см выше), а менеджер временных таблиц передавать через экспортную переменную модуля обычного приложения. Но помню, видела тут изящный вариант, но похоже никто больше на него не обратил внимания, а я как назло не могу найти.

Ой, нехорошо через общую переменную - не будет работать на сервере. Либо параметр сеанса, либо где-то в БД хранить - еще один регистр "удаленных записей" или этот же с признаком "к удалению".

Я решала подобную задачу в Документообороте. Удалось "двойной" заход решить через проверку регистра сведений "история событий". Иначе никак не получалось.