Имеется: 1С Управление торговлей, РИБ из двух узлов. При обмене создаются файлы сообщений типа Message_ЦБ_ПУ.xml . Вопрос можно ли их очистить? И если да, потом в 1С надо будет обнулить номера сообщений?

Сделать можно все - главное понять зачем ?

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

Размер этих файлов в сумме перевалил за 2 гига, при небольшой, на мой взгляд базе. Оно как бы и без разницы, сколько они там весят, но соединение между узлами сделано через hamachi, скорость передачи так себе, и синхронизация идёт очень долго. Поскольку на скорость передачи я повлиять вряд ли смогу, хочу попробовать очистить сообщения, в надежде уменьшить размер файлов и ускорить синхронизацию.

Если я правильно представляю, там сейчас хранится информация об уже синхронизированных данных. Если так, то они уже не нужны, почему бы их не удалить?
Но сомневаюсь, можно ли так. Семь раз отмерь))

(4) если обмен прошел, то файлы можно удалять.

Вообще, часто имя файла оставляют неизменным, чтобы при каждой синхронизации файл перезатирался новым

(4) т.е. опиши последовательность действий, которые 100% тебе известны, когда происходит обмен данными между этими базами

просто перечисли - 1) сформировалось 2) файл упал туда-то и т.п.

(5) так и делаю. Значит, переписывается. Тогда видимо смысла нет его удалять.
Спасибо!

у тебя слишком много объектов зарегестрировано к выгрузке.
конечно можно почистить, но консистентность баз можно сломать

Сделай 1 обмен через флешку

я подозреваю, что обмен идет как-то не так, как должен идти

ну или через фтп перекинь на удаленный комп

(10) скорее всего кто-то просто перепровел документы

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

(6) не очень понял что надо
Запускается синхронизация на ЦБ, на компе в папке создаётся файл Message_ЦБ_ПУ.xml. Комп с периферийным узлом через хамачи подключается к центральному. Запускается синхронизация на нём в ту же папку. То рассказал?

(14) ну и что затем?

напиши номера пакетов обмена в одной и в другой базе

например, в тех обменах, которые отрабатывают в "моих" базах, файл обменов всегда парные, например, Message_ЦБ_ПУ.xml и Message_ПУ_ЦБ.xml . Завершенный, полностью завершенный цикл обмена превращает оба таких файлика в очень маленькие - там внутри них только секции заголовков есть и все.

А как ты делаешь обновления конфигураций в этих базах?

(15) затем обычно проходит синхронизация. Но последнее время идёт очень долго, пользователи прождали часа 2 точно и не выдержав ожидания закрыли всё и позвали меня.

В ЦБ 3/3, в узле 2/0

(18) ну вот! обмен идет только в одну сторону. И не отправляет обратно сообщения "ответки"

(17) да, там тоже парные, забыл написать, прошу прощения. После обмена Message_ПУ_ЦБ.xml  присутствует.

Обновления как положено: сначала центральную, потом синхронизация, обновление приходит в узел, обновляется узел. Тогда всё работало.

(19) Вот я и предполагаю, что из-за низкой скорости хамачи. Потому что даже простое копирование этих файлов на комп-узел уже заняло 3 часа и ещё продолжается.

(20) значит теперь что-то сломалось. Забирай обе базы себе на локалку на тест и мучай программу, чтоб все начало работать правильно.

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

(23) и zip файлы там есть, расширение назвал просто для примера. В архиве всё равно xml лежит

Через 12 минут докопируются файлы на комп с узлом, запущу синхронизацию без хамачи, посмотрю что будет.

На локалке базы есть но там-то таких проблем не возникает. Даже если зарегистрировать все изменения в обеих базах, синхронизация проходит в неадекватные разы быстрее.

(24) а файлы после всех обменов становятся "пустыми" ?

(25) Нет, данные остаются. А разве должны стать пустыми?

(26) конечно!

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

(27) Неверно. Будут сообщения накопившиеся с предыдущей синхронизации. Те что должны уйти из периферийной в центральную.

(28) повторяю

там будут только новые данные, накопившаяся регистрация с момента прошлого обмена, но никак не все данные, которые попали когда-нибудь в обмен.

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

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

(30) ну как намучавшийся в свле время написанием РИБ обмена с нуля :) скажу тебе по секрету.
Если новых данных между обменами не перезаписывапется в базе (там же еще способы регистрации бывают по разному настроены), а только тестить работоспособность, т.е. работу обмена - из обмена всегда "уходят" переданные ранее данные - я и говорю об этом, что они станут "пустые". А скорость обмена будет высокой.

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

Автор ветки, сообщите номера отправленных и принятых сообщений в главном и в подчинённом узлах.

(32) он писал их в пост (18)

(33) Счет игры 2:0 - какая команда выиграла, синие или белые? Юмор понял?

"2/0" - это два переданных сообщения и ни одного принятого или наоборот? Как в ЦБ может быть три сообщения от ПУ, если ПУ передал два сообщения? Лично я ничего не понял и прошу уточнить сколь и каких. Может быть лучше скрины попросить?

(34) Да я думаю, что он все-таки тестить вживую у себя начнет и увидит, разберется. Тогда уже и скрины сделает, если не сможет понять, в чем там срываются обмены

То, что так называемый "односторонний обмен" - это итак понятно. Достаточно сообщения "Размер этих файлов в сумме перевалил за 2 гига" - идёт накопление зарегистрированных изменений. Не исключаю что там ещё и изменение конфигурации висит.

Автору предлагаю посмотреть внимательно на ЖР - высока вероятность, что в базе ПУ при чтении сообщения обмена возникает ошибка (обмен завершается ошибкой).

Будет смешно, если главный узел отказывается принимать данные от узла, для которого зарегистрированы изменения конфигурации, а в ПУ - предлагает открыть конфигуратор или тоже матерится на конфигурацию узла, которая не соответствует ожидаемой  :)

Тема уж пылью поросла, но всё равно отпишусь, вдруг вы за меня переживаете :D

Изменения конфигурации там не было. Большой вес файла объяснился большим количеством зарегистрированных объектов. ПУ не принимал данные с такой вот ошибкой:

Ошибка чтения файла сообщения обмена: {Обработка.КонвертацияОбъектовРаспределенныхИнформационныхБаз.МодульОбъекта(203)}: Ошибка при вызове метода контекста (ЗакончитьЧтение): Ошибка при выполнении обработчика - 'ПередЗаписью': {РегистрСведений.РеестрДокументов.МодульМенеджера(27)}: Ошибка при вызове метода контекста (Записать): Запись с такими ключевыми полями существует! : РеестрДокументов: Перемещение товаров (Документ), Перемещение товаров, ООО "ПРСТ", , , , , 10.11.2017 0:00:00, Перемещение товаров ПУЦБ-000074 от 10.11.2017 0:00:00,  (Регистр сведений: Реестр документов; Номер строки: 2)

Отменил регистрацию у всех документов типа "Перемещение товаров" - синхронизация прошла успешно. Хорошо, конечно, но документы эти тоже надо (причём все).

Дальше проводил тесты:
1) попытка зарегистрировать в  ЦБ все документы "Перемещение товаров", синхронизация вполне логично выдаёт ту же ошибку, завершается, ни одного документа в ПУ не пришло.
2) зарегистрировал все документы "Перемещение товаров" кроме этого проблемного (ПУЦБ-000074). Та же ошибка.
2.1) есть ещё несколько документов с таким же номером, но от разных дат. На всякий случай отменил и их регистрацию тоже. Не помогло, та же ошибка.
3) вообще отменил регистрацию ВСЕХ документов. Создал в ЦБ новый документ "Перемещение товаров", запустил синхронизацию с ним одним. И - ПУ выдаёт ту же ошибку и не принимает документ.

Не пойму вообще что к чему. При чём тут документ ПУЦБ-000074 если его вообще нет в выгрузке?

Всем спасибо за советы!

(38) Так норм получается - это уже прогресс!!!
Есть конкретная причина, которая раскрылась всего-лишь за неделю.

Тебе надо Периферийном узле очистить РегистрСведений перед тем, как начнешь загружать из Центральной базы все документы.

И проблема все же не с собственно документами "Перемещение товаров" - перечитай внимательно текст сообщения об ошибке

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

(38) У планов обмена РИБ есть одна особенность: документы и их движения мигрируют отдельно и независимо друг от друга. Это азбучные истины.

У Вас в подчиненном узле(ПУ) проблема с записями регистра?
Нет проблем!
В ПУ программно очищаем регистр (удаляем все записи регистра); в центральном узле (ЦУ) регистрируем изменения на все записи регистра; с очередным обменом регистр в ПУ будет заново заполнен по записям регистра из ЦУ.
Нет проблем.

Посмотрел регистр "Реестр документов". В ПУ в нём не было вообще никаких записей по перемещениям товаров. Сравнивал с ЦБ - там есть, в ПУ нету.
Всё равно очистил его, зарегистрировал изменения в ЦБ, синхронизирую.. та же ошибка.
Создал вообще новый узел - и там такая же фигня. Только номер "ошибочного" документа другой.

А потом решил обновить на последний релиз (раньше не получилось бы - синхронизация ведь не проходила, а теперь-то можно). И проблема ушла - синхронизация идёт, документы все видны, других ошибок пока что не выявлено.