Подписки на события. Как проконтролировать отказ
Для справочника использую событие подписки "ПриЗаписи", в момент которого справочник переносится в удаленную базу с идентификатором текущей базы. Проблема заключается в том что в Модуле формы справочника если в событии "ПриЗаписи" не заполнен вес происходит Отказ = Истина и объект не записывается.
Из-за этого происходит дублирование справочников, так как обмен идет по уникальным идентификаторам.
Как решит этот момент, у кого какие мысли?
Из-за этого происходит дублирование справочников, так как обмен идет по уникальным идентификаторам.
Как решит этот момент, у кого какие мысли?
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(3) THXO, Нет, из предложенного ничего не поможет
1. Перед записью вызывается до При записи
2. Ссылка нового ввиду имелось ввиду установить, но не имеет никакого смысла
3. Дополнительные свойства также ничего не решат
Так как есть некий порядок который я указал в (2)
Есть дурацкий совсем вариант в подписке ПриЗаписи помещать ссылку в регистр сведений, а по этому регистру идти регламентным заданием, смысл регламентного задания перезаписать объект, если успешно перезаписан тогда указываем статус обработан. Все что обработано уйдет в обмен, то что не обработано просто исчезнет из базы само собой по правилу описанному в (2)
1. Перед записью вызывается до При записи
2. Ссылка нового ввиду имелось ввиду установить, но не имеет никакого смысла
3. Дополнительные свойства также ничего не решат
Так как есть некий порядок который я указал в (2)
Есть дурацкий совсем вариант в подписке ПриЗаписи помещать ссылку в регистр сведений, а по этому регистру идти регламентным заданием, смысл регламентного задания перезаписать объект, если успешно перезаписан тогда указываем статус обработан. Все что обработано уйдет в обмен, то что не обработано просто исчезнет из базы само собой по правилу описанному в (2)
можно так
и далее шаманство с кейсами и значениями свойств, можно с уидами конеш
такой стиль изложения понятнее, хотя и вальяжный, я в курсе)
Объект.ДополнительныеСвойства.Вставить("МодульПодпискиУспех","Ога")
Объект.ДополнительныеСвойства.Вставить("МодульФормыУспех","НеЗнаюНеБылоЯТамаПрограммноШпилю")
Объект.ДополнительныеСвойства.Вставить("МодульФормыУспех","ОгаЯТутаБылоВсеОк")
и далее шаманство с кейсами и значениями свойств, можно с уидами конеш
Если Объект.ДополнительныеСвойства.МодульФормыУспех = "ОгаЯТутаБылоВсеОк" И
Объект.ДополнительныеСвойства.МодульФормыУспех = "Ога"
....такой стиль изложения понятнее, хотя и вальяжный, я в курсе)
что мешает помещать ссылку в доп. свойства объекта во всех вариантах ПриЗаписи(): подписчик, модуль объекта, модуль формы и во всех проверять валидность этого свойства на существование объекта, т.е. если уже создан не откатывать?
(6) THXO, В том то и дело что объект будет существовать, а после события ПриЗаписи в модуле форму он просто исчезнет. Советую внимательно перечитать (2) и попробовать самому. Причина почему нельзя что-то вставить во все модули во все формы очень проста, во первых это не правильный подход, во вторых обмен станет не надежным, после того как кто-то решит для новой формы возвести отказ в истина.
С планами обмена та же песня. Предположим что пользователю при записи система выдала предупреждение, если он ответит нет будет Отказ = Истина. Пользователь получил предупреждение и пошел по своим делам. В этот момент происходит чтение изменений для РБД и записи улетают в другую базу. Пользователь приходит и нажимает "нет". Получаем ситуацию когда в источнике нет данных а в приемнике есть.
Еще раз повторюсь, что для меня проблема если какой-то программист напишет в модуле формы Отказ = Истина, тогда у меня будут дубли, а так как обмен в реальном времени и 1с не поддерживает распределенные транзакции, то становиться печально. Причем дубли уже выявились на этапе тестирования.
(20) Немного не так. Он там записан на время выполнения процедуры и может быть удален непосредственно если будет отказ. В этот же момент идет регистрация изменений. Далее происходит отказ и объект удаляется из базы, а в регистрации изменений остается битая ссылка.
(23) Для того, чтобы иметь возможность откатывать транзакции.
Может я неправильно выразился - я имел ввиду, что логика вашего решения - извращена. Вероятнее всего необходимо записывать документ в режиме обмена данными. А после окончания всех контроле запускать процедуру регистрации объектов в планах обмена.
Может я неправильно выразился - я имел ввиду, что логика вашего решения - извращена. Вероятнее всего необходимо записывать документ в режиме обмена данными. А после окончания всех контроле запускать процедуру регистрации объектов в планах обмена.
(26) Ты неправильно понял. Это не мое решение, мне не нужно было это контролировать и это никак не решается. Я столкнулся с этим в чужой самописной где были зарегистрированы такие ошибки. Причина их была в Отказ = Истина в событии ПриЗаписи. При использовании планов обмена не должно быть отказа при записи иначе будут битые ссылки. Просто перенесли проверки в событие ПередЗапиью.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот