В РБД наборы записей регистров регистрируются раньше, чем их регистраторы? #304213

Заметили, что при переносе данных вручную (отключена авторегистрация для некоторых объектов) в Распределенной Базе Данных в процедурах "ПриОтправкеДанныхПодчиненному" и "ПриОтправкеДанныхГлавному" плана обмена наборы записей регистров регистрируются раньше, чем их регистраторы. В итоге ссылок на регистраторы в момент переноса регистров нет. Вопрос, как-нибудь можно управлять порядком регистрации объектов метаданных в этих процедурах?

А зачем и где это нужно? При  приеме или отправке?

Это нужно для ограничения переноса документов и их движений в зависимости от склада, указанного в документе. (Для каждого узла задан список складов). Т.е. если документ не затрагивает склады, указанные в табличной части узла, то он не переносится на этот узел. Это нужно при отправке данных, чтобы сообщения были меньше (не содержали лишних данных), и, соответственно, грузились и передавались быстрее.

Через распределенку этого не сделать. Там невозможно выделить часть движений. Нужно писать свой.

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

Да, это вообще вопрос интересный... если выгружать только документы и уже на месте проводить? зачем в 1с движения по регистрам грузятся ОТДЕЛЬНО? Ну да, база приемник может быть совсем другой и движения в базе отправителе могут не совпадать с движениями в базе приемнике, так что ли?

RTFM - очень полезное занятие. Среди прочего там сказано, что порядок выгрузки/загрузки (читай - регистрации) объектов в РБД - не определен, управлять этим нельзя (ну может кроме последних релизов 8.1). Если исключается целиком набор записей - это можно сделать при выгрузке данных. При загрузке данных такая ситуация может легко возникнуть - загружен набор записей регистра, а его регистратора еще нет. Это нормальная ситуация, криминала нет никакого. Потому, что наборы записей и документы - это отдельные сущности, и у проведенного документа может не быть движений (обратное также верно).

Мы у себя решили этот вопрос так. Создали план обмена без галочки РИБ. В момент выгрузки через запросы фильтруем табличные части документа, подменяем нужные реквизиты и отправляем в периферийный узел. А уже там перепроводим. У нас так обмениваются взаиморасчеты довольно давно и успешно.

SilentMan, тут по твему мнению идиоты одни сидят что ли? Там проверка "Это загрузка" есть, чтобы не выполнять стандартных проверок, и записывать при загрузке объекты, некоторые реквизиты которых еще не пришли по обмену . Ты что тут ответил? Вопрос был о сути перегрузки, ЗАЧЕМ движения грузить так, и что благодаря этому можно получить?

Уточнение - например в 7.7 бухии это реально нужно, если проводки скорректированы ручками, то переносить надо именно движения - МОД в этом плане очень продвинутая прога, например была задача создать из субсчета группу, соответственно движений по группе быть не может, по стандарту пришлось бы перепровести все документы за 5 лет а там ручных корректировок было... Создали субсчет (надо было перекинуть 68.2 на 68.2.2 перекинуть, вроде бы так) и перегрузили БД. В общем за пару часов управились.

При "ПриОтправкеДанныхПодчиненному", для элемента данных РегистрНакопления, доступен и его регистратор, (ЭлементДанных.Отбор.Регистратор.Значение.ТутТоЧтоТебеНабоСравнить) и соответственно движения можно либо выгрузить либо нет. ЭлементДанных.Отбор.Регистратор.Значение.Номер - это НомерДокумента ЭлементДанных.Отбор.Регистратор.Значение.Склад - это склад из документа Удачи.

Блин!!!!!  Слава, а как я по твоему на 20 филиалов обмен делал по реквизиту склад? Неким чудным образом без регистратора что ли? (о наборах записей сейчас говорю)  Процедура которую ты описал есть только в УРБД, в обычном обмене её нет. Речь то идет о том, что есть вот какой вопрос - для экономии места я могу выгрузить ТОЛЬКО документы, и в базе - приемнике их ПРОВЕСТИ. При тех объемах выгрузок это экономит кучу времени на собственно выгрузку и загрузку, проверка по регистратору очень много времени занимает.

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

нет, галочку распределенная база у нас не отключена. Но отключена авторегистрация для некоторых объектов и обмен прописан вручную. SilentMan прав во всем. Именно так и получается, что движения отдельно, а документы отдельно. Даже создали свою обработку, проверяющую правильность переноса на этапе коддинга. Интересная инфа. т.е в последних релизах порядком загрузки объектов можно управлять? В каком именно?

А документы нам проыодить потом не надо, так как движения по регистрам тоже прописываем. Кстати, "ЭлементДанных.Отбор.Регистратор.Значение.ТутТоЧтоТебеНабоСравнить" как раз и не срабатывает. Если набор записей грузится раньше самого документа, которого еще нет в базе. То объект не найден. Решили проблему так - смотрим у первой записи склад. он там есть всегда.(  ну или свертка по складу для перемещений и смотрим 2 записи)

ILNIK - При ОТПРАВКЕ данных объект в базе есть, сравнивать есть с чем. вот "При ПОЛУЧЕНИИ данных от главной" его нет, это верно.

прав. И если мы хотим этим рулить, то фильтровать надо именно при выгрузке в подчиненный.

Не очень понятно, к чему этот коммент. Я понял только самый первый вопрос, поэтому на него и отвечу - тут сидят не одни идиоты. Если ты конкретизируешь остальные вопросы - отвечу и на них. Я был не совсем прав - там нельзя управлять порядком, там можно делать запросы к таблицам регистрации (это несколько разные вещи). При этом делать выгрузку по результатам запроса (с автоотметкой о номере исходящего пакета) нельзя :( Непонятно одно - зачем делать фильтрацию при загрузке, если проще и дешевле сделать ее при выгрузке? Периферия должна тупо принять данные, которые ей предоставили.

Самое правильное - рулить контролем выгрузки (куда грузим куда нет)  прямо при модификации документа. Задержка при проведении на 0.1-0.3 секунды (проверка различных условий, в зависимости от которых происходит регистрация изменений) никакого влияния не окажет, а вот анализ сложных вариантов обмена в процедурах плана обмена (когда изменения зарегистрированы для всех баз) - может быть очень длительным процессом... Как вариант - регламентная выгрузка в нерабочее время, есть даже свои плюсы, но если обмен должен идти несколько раз в день и документооборот большой это не покатит.

Мы так и делаем. При проведении дока смотрим у него склад и добавляем нужные узлы в обмен. А при выгрузке данных смотрим объект и устанавливаем режим его передачи (авто, игнорировать, удалить). Стуация, когда не найден объект регистратора у набора записей возникает когда объект приходит на другой узел и сразу регистрирует себя для передачи в другие узлы. Но так как регистратор еще не поступил (он был только что создан и в отправителе и в текущем узле отсутствует), то объект не найден. А мы проверяли у регистратора склад. Возникала ошибка. Поэтому теперь проверяем склад у первой записи набора записей регистра. Он там есть, даже когда регистратор не найден. А то что управлять порядком приема объектов нельзя очень плохо ((((

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

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

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

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

ну и задачки вы ставите! Боюсь, что ссылочная целлостность восстановится не раньше второго цикла обмена. ))) Я ж говорю, пока мы работаем только с одним регистром. И при этом ссылочная целлостность нарушена много раз. Например, отчеты показывают какие-то результаты, а документов-то нет. ) Но работа над этим продолжается.

а интересно, как данный пример решается внутренним механизмом, с включенной авторегистрацией?

не вижу как ссылочная целостность может нарушиться после уже всего лишь полного прочтения одного сообщения

Я стормозил. Конечно, ссылки будут и за одно сообщение. Просто в процессе чтения сообщения объекты( например, регистраторы), могут отсутствовать. Потом все восстановится. А насчет двух проходов при загрузке - тоже мысль. Т.е. сначала грузить всё. А потом уже на втором проходе делать то, что нужно нам. Только как организовать это? Вызов системных процедур, таких как "при получении..." или "приОтправке..." происходит системно.

Еще раз - не надо фильтровать при загрузке! Это аксиома! Проблем очень много, а пользы практически нет. Загрузка и так процесс небыстрый...

это типа транзитом через узел в другой?

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

2 "SilentMan". еще раз говорю - при загрузке мы не фильтруем! Происходит то, что говорит "ОчкарикСлава". т.е. если объект посылается с режимом "удалить", то он удалится во всех узлах и на всех уровнях. Только вот у нас стоит ограничение по складам, которые задаются в табличных частях узлов т.е. если склад из дока не прописан в узле, то этот документ удаляется в этом узле либо туда не посылается.

а как организовать 2 прохода - видимо убрать галку "распределёнка" на плане обмена и писать свою обработку загрузки и выгрузки. Изменения конфигурации тогда - другим планом обмена с галкой "распределёнка" но без данных в составе хотя блин может проще тогда 2 плана обмена один для обмена уровней 1 и 2, другой для уровней 2 и 3 скажем

Тогда об чем мы тута обчаемся? :)

А то что управлять порядком приема объектов нельзя ((((