v8: РИБ. Аварийное завершение работы при обмене #586374

Добрый день! Сначала возникла проблема при обмене между центральной базой и периферийной базой: конфигурация не соответствует ожидаемой. Эту проблему устранила(или так кажется). На форуме есть по этому поводу масса рекомендаций: отсоединила периферийную базу от главного узла, загрузила в нее конфигурацию центральной базы и снова соединила базу с главным узлом. Делаю обмен. Минут через 40 происходит аварийное завершение работы. Создала в главном узле новое сообщение. Ситуация не изменилась. Перезапускала службу 1с агент, загружать пробовала не в одной транзакции а порциями по 100 элементов. В общем, обращаюсь к экспертам, может возможно реанимировать обмен как -то?

может место кончилось.

в крайнем случае можно снова выгрузить перефирийную базу.

База на SQL, насчет места не знаю, надежды мало, но спрошу у сисадмина, который за этим следит

выгрузить периферийную базу - это новый образ создать? Только что делать с различиями в данных в старом образе? Их же надо подтянуть.

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

Если не поможет, то отливаете образ, а потом загрузкойвыгрузкойXML подтягиваете данные из периферийной базы

Так оно работать в распределенке)

кэш почисти, место все-таки проверь, если не помогло то в последний шанс.

Спасибо всем огромное. Буду сегодня вечером пробовать.

Это типовой план обмена?

ага! интересует вот это: "загружать пробовала не в одной транзакции а порциями по 100 элементов. " - в журнале регистрации при этом пишутся записи о том что такое-то объекты изменены.. вот после сваливания после 40 минут загрузки - можно определеить порцию на которой это происходит? Возможно ли также поставить загрузить порциями по 1 в транзакции, и в это же время следить в другом сеансе за Журналом Регистрации, все время нажимая PgDn? чтобы определить на каком объекте валиться?

типовой план обмена

я понял, в рецепт как увидеть сбойный объект, а потом его уже исследовать

но 40 минут ..

тогда пусть не ждет, тогда пусть смотрит после падения последний загруженный, открывает ХМЛ-файл, и смотрит какой следующий объект в файле после успешно загруженного

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

в общем, проблема решена. Еще раз все спасибо за помощь.

2 на каком?

не на типовом, на своем.

просто идет внедрение и все работают в жестком режиме. Я на этом проекте совсем недавно и с моим приходом совпала эта проблема.

а в режиме предприятия из этого объекта данные пока могут быть прочитаны?

да. Возможно ресурсы

виндов заканчиваются при загрузке большого количества элементов этого регистра. Хотя я следила за памятью, ничего не заметила.

не, погодите, вы говорите что с этим объектом нет пока проблем при обмене, вы говорите что с ним проблемы при тестировании и исправлении... Так вот - несмотря на тот факто что ТиИ на нем валиться, в режиме предприятия элементы или записи этого объекта могут быть прочитаны? например обычным запросом

релиз какой?

При обмене нет проблем с регистром на котором ТИС валится, потому что его нет в плане обмена. Я пока не знаю для чего был создан этот объект и какую смысловую нагрузку несет. Но с ним работают. 1С:Предприятие 8.2 (8.2.13.219) Управление производственным предприятием, редакция 1.3 (1.3.12.1)