перешел на последний релиз, основная база нормально апнулась :)
а вот УРБД - нет, есть подчиненный узел по плану обмена "полный", в нем при обновлении вылетает на последнем операторе процедуры "ОбновитьТарифСтраховыхВзносов", и самое интересное, что 1с перестает запусктся в пользовательском режиме. Подозреваю что это косяк в правах, кто сталкивался?

Процедура ОбновитьТарифСтраховыхВзносов(Тариф, ТаблицаТарифов = Неопределено)

   Если ТаблицаТарифов = Неопределено Тогда
       ТаблицаТарифов = ТаблицаТарифовСтраховыхВзносов();
   КонецЕсли;
   
   НаборЗаписей = РегистрыСведений.ТарифыСтраховыхВзносов.СоздатьНаборЗаписей();
   НаборЗаписей.ДополнительныеСвойства.Вставить("ЗаписьОбщихДанных");
   НаборЗаписей.Отбор.ВидТарифа.Установить(Тариф);
   НаборЗаписей.Загрузить(ТаблицаТарифов.Скопировать(Новый Структура("ВидТарифа",Тариф)));
   НаборЗаписей.Записать();
   
КонецПроцедуры

а ты в подчиненный узел админом после обновления заходишь? если да, то косяк явно не в правах :)
а вообще стандартное решения. Отвязал от центра, обновил, снова привязал.

(1) в режиме предприятия не входит... ни в обычном режиме ни в УФ.

(1)>> а ты в подчиненный узел админом после обновления заходишь? если да, то косяк явно не в правах :)
а вообще стандартное решения. Отвязал от центра, обновил, снова привязал.

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

(1)А вообще моя стандартная практика за 8 лет работы с УРБД на 1с - такая - Я запрещаю запуск в 1с обновления в подчиненом узле.
Ибо - конфу головной узел передаст и измененые объекты - тоже - те что пересчитались в головном узле.

+(4)данная практика не разу не давала осечек.
Ибо до этого обычно забывали про подчиненный узел. А если распределенка 2-3 звенная и большая - то поток данных гонялся по кругу.
А в Бух 3.0 - вообще жесть - у нас с января - так там типа про распределенку вообще типа забыли.
Спасибо сразу поставил запрет на запуск ЛЮБЫХ обработчиков и пересчета в подчиненом узле. Ибо - что надо - центр передаст

(3) это вы уважаемый не путайте практику с решением и тоже бред ни пишите.

(3) Ага, а данные, что еще не загрузились в головную базу не будут обработаны - хорошо-то как

(7)Все там нормально загрузится.
Прочитайте внимательно - запрет на запуск в подчиненом узле ЛЮБЫХ ОБРАБОТОК ОБНОВЛЕНИЯ и пересчета.
Ибо - пересчитанные данные придут из головного узла.
7 лет так делаю в 1с8 и с января в бух 30 - проблем нет - все прогружается и работает.

не сочтите на труд, прочтите тему и п.28 из v8: Ограничение доступа на уровне записей . Это косяк я поймал на контрагентах, которые были изменены в подчиненном узле и пришли с первыи обменом после обновления.

Предпологаю что механизм обновления базы данных центрального и подчиненных узлов имеет различия... и они - не в лучшую сторону.

PS: имхо, чисто голословное утверждение, без доказательное.

(8) Ниче там не загрузится, т.к. данные, которых нет в Центре не обработаются обработкой обновления, а в дочке она у тебя не запускается.

Как обработаешь данные?

(8) "Ибо - пересчитанные данные придут из головного узла" - не факт, далеко не факт. Обновляемые данные могут быть не включены в план обмена или на них может быть не будет зарегистровано изменение.

(8) А если там обменданными.загрузка = истина при обновлении?

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

Тьфу. "подчиненном объекте" --> "подчиненном узле"

(8) ну-ну... смотри, как бы разгребать не пришлось...

(0) И как всегда, увы, платформа не озвучена. А я ведь помню любовь ТС к старым платформам :) Имхо: последние обновления конфигураций весьма критичны для старых платформ - они тупо ломают базы УРБД после обновления :(

1С:Предприятие 8.2 (8.2.18.61)
Бухгалтерия предприятия, редакция 3.0 (3.0.21.14)

В регистре сведений "ВидТарифа" - это перечисление. Глупо звучит, понимаю, но ты всё-таки попробуй запросом проверить "корректность" этих значений.

(11),(13),(15) Ну во первых правится и план обмена - включаются все необходимые данные (кроме КЛАДРА и настроек обмена и проч подобное). Т.е. считаем что все делает головной узел.
Во вторых, конечно проверяются обработчики которые запускаются при обновлении. И если НАДО - РУКАМИ запускаем в подчиненом узле. Но ситуация когда это требуется - исключительная и крайне редкая.

Зато данный процесс позволяет РЕЗКО ПОВЫСИТЬ скорость работы и обмена.

Если грамотно а не тупо подойти - косяков нет.
Еще раз - так делаю лет 7. И все нормально.
Разумеется надо все проверять сначала.

Но просто когда у вас 1-2 распределенки - фигня. Я работал - было 12-32 филиала - в одном ж.опа будет - и пипец всем!

+(19)в указанном случае больше тратится времени на разбор механизма что и где запускается и что добавили для пересчета. Но зато исключает гемор на конечных точках

нашел косяк

вообще дело было в нештатной подписке, но идеологически там то же не все гладко, общие данные регистрятся в обмене...

(21) ага-ага.
скорее всего в этой самой "нештатной" подписке нет проверки на   ОбменДанными.Загрузка, из-за чего она будет ловить ЛЮБЫЕ изменения.

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

(22) разумеется есть :) подписка предназначена для исключения изменения определенных данных в переферийки.

она и сработала, сам писал и сам вляпался :)