Вход | Регистрация


1С:Предприятие ::

Метки: 

Можно ли очистить сообщения в РИБ?

Я
   Мефа
 
07.09.18 - 13:31
Имеется: 1С Управление торговлей, РИБ из двух узлов. При обмене создаются файлы сообщений типа Message_ЦБ_ПУ.xml . Вопрос можно ли их очистить? И если да, потом в 1С надо будет обнулить номера сообщений?
 
 
   Tatitutu
 
1 - 07.09.18 - 13:36
Сделать можно все - главное понять зачем ?
   Фрэнки
 
2 - 07.09.18 - 13:37
попробуй сформулировать возникшую проблему, чтоб мы здесь поняли чего ты хочешь
   Мефа
 
3 - 07.09.18 - 13:55
Размер этих файлов в сумме перевалил за 2 гига, при небольшой, на мой взгляд базе. Оно как бы и без разницы, сколько они там весят, но соединение между узлами сделано через hamachi, скорость передачи так себе, и синхронизация идёт очень долго. Поскольку на скорость передачи я повлиять вряд ли смогу, хочу попробовать очистить сообщения, в надежде уменьшить размер файлов и ускорить синхронизацию.
   Мефа
 
4 - 07.09.18 - 13:58
Если я правильно представляю, там сейчас хранится информация об уже синхронизированных данных. Если так, то они уже не нужны, почему бы их не удалить?
Но сомневаюсь, можно ли так. Семь раз отмерь))
   1Сергей
 
5 - 07.09.18 - 14:00
(4) если обмен прошел, то файлы можно удалять.

Вообще, часто имя файла оставляют неизменным, чтобы при каждой синхронизации файл перезатирался новым
   Фрэнки
 
6 - 07.09.18 - 14:11
(4) т.е. опиши последовательность действий, которые 100% тебе известны, когда происходит обмен данными между этими базами

просто перечисли - 1) сформировалось 2) файл упал туда-то и т.п.
   Мефа
 
7 - 07.09.18 - 14:12
(5) так и делаю. Значит, переписывается. Тогда видимо смысла нет его удалять.
Спасибо!
   Вафель
 
8 - 07.09.18 - 14:12
у тебя слишком много объектов зарегестрировано к выгрузке.
конечно можно почистить, но консистентность баз можно сломать
   Вафель
 
9 - 07.09.18 - 14:12
Сделай 1 обмен через флешку
   Фрэнки
 
10 - 07.09.18 - 14:13
я подозреваю, что обмен идет как-то не так, как должен идти
 
 Рекламное место пустует
   Вафель
 
11 - 07.09.18 - 14:13
ну или через фтп перекинь на удаленный комп
   Вафель
 
12 - 07.09.18 - 14:13
(10) скорее всего кто-то просто перепровел документы
   Фрэнки
 
13 - 07.09.18 - 14:14
(12) нет. скорей всего, он не завершает цикл обмена, хотя по идее должен его завершать, но не понимает, что это нужно делать
   Мефа
 
14 - 07.09.18 - 14:19
(6) не очень понял что надо
Запускается синхронизация на ЦБ, на компе в папке создаётся файл Message_ЦБ_ПУ.xml. Комп с периферийным узлом через хамачи подключается к центральному. Запускается синхронизация на нём в ту же папку. То рассказал?
   Фрэнки
 
15 - 07.09.18 - 14:19
(14) ну и что затем?
   Фрэнки
 
16 - 07.09.18 - 14:20
напиши номера пакетов обмена в одной и в другой базе
   Фрэнки
 
17 - 07.09.18 - 14:24
например, в тех обменах, которые отрабатывают в "моих" базах, файл обменов всегда парные, например, Message_ЦБ_ПУ.xml и Message_ПУ_ЦБ.xml . Завершенный, полностью завершенный цикл обмена превращает оба таких файлика в очень маленькие - там внутри них только секции заголовков есть и все.

А как ты делаешь обновления конфигураций в этих базах?
   Мефа
 
18 - 07.09.18 - 14:25
(15) затем обычно проходит синхронизация. Но последнее время идёт очень долго, пользователи прождали часа 2 точно и не выдержав ожидания закрыли всё и позвали меня.

В ЦБ 3/3, в узле 2/0
   Фрэнки
 
19 - 07.09.18 - 14:27
(18) ну вот! обмен идет только в одну сторону. И не отправляет обратно сообщения "ответки"
   Мефа
 
20 - 07.09.18 - 14:28
(17) да, там тоже парные, забыл написать, прошу прощения. После обмена Message_ПУ_ЦБ.xml  присутствует.

Обновления как положено: сначала центральную, потом синхронизация, обновление приходит в узел, обновляется узел. Тогда всё работало.
   Мефа
 
21 - 07.09.18 - 14:29
(19) Вот я и предполагаю, что из-за низкой скорости хамачи. Потому что даже простое копирование этих файлов на комп-узел уже заняло 3 часа и ещё продолжается.
   Фрэнки
 
22 - 07.09.18 - 14:29
(20) значит теперь что-то сломалось. Забирай обе базы себе на локалку на тест и мучай программу, чтоб все начало работать правильно.
   Фрэнки
 
23 - 07.09.18 - 14:32
(21) файлы обмена не зипованные создаются... а скорость низкая... нет. что-то надо оттестить без хамачи, настроить, чтоб пакеты получались поменьше, чтоб на низкой скорости соединения не глючили. Но без получения "ответки" - это нужно отменять регистрацию данных по узлу, чтоб перезапустить обмен на "пустых" пакетах
   Мефа
 
24 - 07.09.18 - 14:47
(23) и zip файлы там есть, расширение назвал просто для примера. В архиве всё равно xml лежит

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

На локалке базы есть но там-то таких проблем не возникает. Даже если зарегистрировать все изменения в обеих базах, синхронизация проходит в неадекватные разы быстрее.
   Фрэнки
 
25 - 07.09.18 - 14:50
(24) а файлы после всех обменов становятся "пустыми" ?
   Мефа
 
26 - 07.09.18 - 14:58
(25) Нет, данные остаются. А разве должны стать пустыми?
   Фрэнки
 
27 - 07.09.18 - 15:03
(26) конечно!

Ты получаешь ответку с периферийки и если в этот самый момент, сразу после ответки, сделаешь выгрузку, то там будут только новые данные, накопившаяся регистрация с момента прошлого обмена, но никак не все данные, которые попали когда-нибудь в обмен.
   arsik
 
28 - 07.09.18 - 15:09
(27) Неверно. Будут сообщения накопившиеся с предыдущей синхронизации. Те что должны уйти из периферийной в центральную.
   Фрэнки
 
29 - 07.09.18 - 15:10
(28) повторяю

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

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

Кстати, при обмене на канале с низкой скоростью, как раз уменьшают размер передаваемых пакетов, делая обмен чаще, чтоб получалось переварить. Также часто модифицируют процедуру записи пакета, чтоб сделать его меньшего объема, но передавать все данные не одним тактом цикла, а неким множеством.
   Serg_1960
 
32 - 07.09.18 - 15:33
Автор ветки, сообщите номера отправленных и принятых сообщений в главном и в подчинённом узлах.
   Фрэнки
 
33 - 07.09.18 - 15:33
(32) он писал их в пост (18)
 
 
   Serg_1960
 
34 - 07.09.18 - 15:43
(33) Счет игры 2:0 - какая команда выиграла, синие или белые? Юмор понял?

"2/0" - это два переданных сообщения и ни одного принятого или наоборот? Как в ЦБ может быть три сообщения от ПУ, если ПУ передал два сообщения? Лично я ничего не понял и прошу уточнить сколь и каких. Может быть лучше скрины попросить?
   Фрэнки
 
35 - 07.09.18 - 15:45
(34) Да я думаю, что он все-таки тестить вживую у себя начнет и увидит, разберется. Тогда уже и скрины сделает, если не сможет понять, в чем там срываются обмены
   Serg_1960
 
36 - 07.09.18 - 15:53
То, что так называемый "односторонний обмен" - это итак понятно. Достаточно сообщения "Размер этих файлов в сумме перевалил за 2 гига" - идёт накопление зарегистрированных изменений. Не исключаю что там ещё и изменение конфигурации висит.

Автору предлагаю посмотреть внимательно на ЖР - высока вероятность, что в базе ПУ при чтении сообщения обмена возникает ошибка (обмен завершается ошибкой).
   Serg_1960
 
37 - 07.09.18 - 16:02
Будет смешно, если главный узел отказывается принимать данные от узла, для которого зарегистрированы изменения конфигурации, а в ПУ - предлагает открыть конфигуратор или тоже матерится на конфигурацию узла, которая не соответствует ожидаемой  :)
   Мефа
 
38 - 13.09.18 - 14:03
Тема уж пылью поросла, но всё равно отпишусь, вдруг вы за меня переживаете :D

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

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

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

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

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

Всем спасибо за советы!
   Фрэнки
 
39 - 13.09.18 - 14:09
(38) Так норм получается - это уже прогресс!!!
Есть конкретная причина, которая раскрылась всего-лишь за неделю.
   Фрэнки
 
40 - 13.09.18 - 14:13
Тебе надо Периферийном узле очистить РегистрСведений перед тем, как начнешь загружать из Центральной базы все документы.

И проблема все же не с собственно документами "Перемещение товаров" - перечитай внимательно текст сообщения об ошибке
   Фрэнки
 
41 - 13.09.18 - 14:18
Возможно что весь РеестрДокументов очищать не захочешь (не знаю есть ли от него какой-то практический смысл в периферийном узле), но отбери тогда из этого регистра записи для Перемещений, удали их и грузи Перемещения вновь, да и все.
   Serg_1960
 
42 - 13.09.18 - 15:21
(38) У планов обмена РИБ есть одна особенность: документы и их движения мигрируют отдельно и независимо друг от друга. Это азбучные истины.

У Вас в подчиненном узле(ПУ) проблема с записями регистра?
Нет проблем!
В ПУ программно очищаем регистр (удаляем все записи регистра); в центральном узле (ЦУ) регистрируем изменения на все записи регистра; с очередным обменом регистр в ПУ будет заново заполнен по записям регистра из ЦУ.
Нет проблем.
   Мефа
 
43 - 17.09.18 - 13:50
Посмотрел регистр "Реестр документов". В ПУ в нём не было вообще никаких записей по перемещениям товаров. Сравнивал с ЦБ - там есть, в ПУ нету.
Всё равно очистил его, зарегистрировал изменения в ЦБ, синхронизирую.. та же ошибка.
Создал вообще новый узел - и там такая же фигня. Только номер "ошибочного" документа другой.

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



Список тем форума
Рекламное место пустует Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Рекламное место пустует