Проблемы с удалением элементов справочников в УРБД #372537

Есть распределенная база с 2мя узлами Центральным и периферийным. Обмен идет в обе стороны, а передаются только справочники. Опишу в кратце проблему: Допустим в Центральной базе пришел товар, оформили поступление документом и осуществили обмен с Периферийной, после чего в ней появляется номенклатура, затем её помечают на удаление и удаляют через операции удаляем без проблем, потому что документа нет(он не передается). Меняемся обратно и номенклатура пропадает в центральной базе. Была идея ограничить права на удаление в Периферийной базе, но это не устраивает заказчика. Какие пути еще могут быть???

Извените забыл указать, что это 1с версии 8

не принимать удаление объектов от подчиненного, или вообще эти удаления не регистрировать

Каким образом это можно реализовать?

Есть в плане обмена процедура ПриПолученииДанныхОтПодчиненного, но что там нужно прописать, чтобы удаления не принимались ?

Что именно необходимо дописать, чтобы элементы не удалялись или изменения для удаленных объектов не регистрировались в центрально???

1. Вариант ПриПолученииДанныхОтПодчиненного(<Элемент данных>, <Получение элемента>, <Отправка назад>) Параметры: <Элемент данных> При вызове обработчика события данный параметр содержит элемент данных, прочитанный из сообщения обмена данными. Элементами данных могут быть КонстантаМенеджерЗначения.<Имя константы>, объекты базы данных, наборы записей регистров, последовательностей или перерасчетов. Думаю при получении информации об удаленном объекте, тип "Элемент данных" будет "УдалениеОбъекта". Если получаем данные такого типа - отказываемся от загрузки. Для Этого используем второй параметр <Получение элемента>. 2й вариант. Снимаем автоматическую регистрацию данных для нужных справочников в главной базе. создаем подписку на событие нужных справочников "При записи". В подписке для нужных узлов делаем регистрацию изменений. Факт удаления объекта в этом случае не будет фиксироваться вообще и в подчиненной базе ничего делать не нужно.

Скорее всего выберу первый вариант. Спасибо за грамотный и быстрый ответ.

Согласен с но хочу уточнить :) в РИБ-базе можно: При получении данных - проверить объект на наличие ссылок. Если есть ссылки - надо а) проигнорировать удаление и б)зарегистрировать изменение для узла - "источника" удаления. Объект не будет удалён, а будет передан в узел, где он будет записан заново - но со "старым" идентификатором (т.е. будет "восстановлен")

Если не трудно примерчик реализации 2 варианта. Допустим называется РаспределеннаяБаза, значение для справочников установлены в плане обмена Авторегистрация-Запретить, Центральный узел и Периферийный. Что дальше нужно прописать в процедуре подписки??? Еще есть один вопросик по созданию начального образа базы пишу такой код(На форме есть элемент ПолеВводаОтделение с типом ПланОбменаСсылка.РаспределеннаяБаза): Выдает ошибку, пробовал Менять Узел=ЭлементыФормы.ПолеВводаОтделение.Значение.ПолучитьОбъект, 1с в обоих случаях говорит что ошибка во втором параметре. В чем не прав???

С созданием образа разобрался, всё работает. По поводу . Т.е. если правильно понимаю нужно проверить какой-то командой наличие ссылки и отправить назад, если есть. Как можно проверить наличие ссылок и правильно ли я вас понял???

Синтаксис: НайтиПоСсылкам(<Список ссылок>) Параметры: <Список ссылок> (обязательный) Тип: Массив. Массив со списком ссылок на объекты, ссылки на которые нужно найти. Возвращаемое значение: Тип: ТаблицаЗначений. Возвращает ссылки на найденные объекты в виде ТаблицаЗначений, состоящей из колонок с индексами: 0 - искомая ссылка; 1 - ссылка на объект, если найдена ссылка в объектной таблице; ключ записи, если ссылка найдена в независимом регистре сведений; ссылка на документ-регистратор для всех остальных необъектных таблиц; 2 - объект метаданных, которому соответствуют данные из колонки 1. Описание: Осуществляет поиск ссылок на объекты, переданные в параметре <Список ссылок>. Пример:

Пример использования:

Сенкс всё реально работает.

написал

*:о)

Мне больше нравиться второй вариант на основе "ручной" регистрации изменений. В этом случае очень удобно сортировать данные по получателям. Т.е например в подчиненной базе можно отказаться от выгрузки определенных данных в центральную, например анализировав иерархию элемента справочника Номенклатура и на ее основе принимая решение в какой узел необходимо ее отослать. В этом случае ничего нигде удалять не нужно будет. а в случае большого объема данных сократит размер пакетов.

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

+1. Согласен. Но, если есть ситуация, когда в одной базе удаляют номенклатуру в ней не использующуюся, а в другой базе она используется... Не логичнее ее вообще не отправлять?

Можно не отправлять - но тогда как узнать что удалять нельзя?

А тогда удалять будет нечего. В подчиненной базе будет общая номенклатура и специфичная только для нее. Основная сложность знать наверняка где какая :)

Второй вариант в ограничен "в применении" и не возможен "в принципе" когда удаление разрешено в различных узлах с различным составом объектов. Проще всего организовать удаление только в корневом узле, - и тогда, когда он "консолидирует" все объекты подчиненных узлов. В базах различный состав документов? Это допустимо :) Но различный состав (содержимое) справочников :( - не верное решение. Их содержимое должно быть "общее" и "единое" - так будет "правильнее". Особенно, если учитывать возможность различного рода изменений в будущем...

Их содержимое должно быть "общее" и "единое" - так будет "правильнее".  + стотыщпицот :) Нефиг удалять вообще нигде. Завели элемент, пусть будет, есть не просит.  Удачи, пора по домам.

Пока, по норам пора :)