Восстановление данных 1С8 при помощи механизма РИБ
Предлагаю сообществу способ восстановления утраченных данных из бэкапа используя механизм РИБ. Зачастую наличие бэкапа базы не позволяет просто взять и откатить состояние базы на утро или вечер предыдущего дня. Бывает так, что утерю важных данных заметили спустя 2 дня, и свежий бекап нам не поможет. Предлагаю относительно простой способ переноса определенных данных из резервной копии базы в рабочую. Не надо писать обработку по выгрузке, загрузке данных или по переносу через COM-соединение. Единственное условие: в базе должны работать обмены РИБ.
- Описание
- Подробнее
Описание
Предыстория: Случилось ЧП. В центральной базе сети магазинов пропали цены на большую часть номенклатуры. Магазины выполнили обмен и тоже лишились цен. Торговля встала. Как выяснилось, в одном из филиалов товаровед удалил "лишние" документы. Соглашусь, здесь явный недостаток в настройке обменов. Этих "лишних" документов у филиала вобще не должно было быть. Но проблему нужно решать и быстро. Решение лежало на поверхности. Раз документы пропали после обмена, надо поискать узел, который не успел загрузить "убийственный" пакет, перепровести документы, каким-то образом проигнорировать загрузку изменений из центральной базы и выгрузить обратно нужные документы. Увы, таких узлов не оказалось. Нужные документы остались только в бэкапах.
Идея: У нас есть бэкап с нужными документами. Мы знаем, что эти документы ходят по обменам через РИБ. Писать обработку для переноса документов нет времени. Попробуем обмануть РИБ и переслать эти документы через файл сообщения, как-будто из периферийной базы.
Реализация: Оповещаем всех, чтобы не делали обмены в рабочей базе. В резервной копии открываем планы обмена, любой рабочий узел. Я использовал узел филиала "виновника", пусть знает. Штатными средствами удаляем все зарегистрированные изменения по выбранному узлу. В УТ 2.3 (10.3 — для России) это делается на форме "Регистрация изменений для плана обмена" (Иконка мониторчик). В других конфигурациях должны быть свои средства. Если же таких средств нет, то можно написать простейшую обработку с кодом:
Процедура УдалитьРегистрацию()
ПланыОбмена.УдалитьРегистрациюИзменений(ВыбУзел);
КонецПроцедуры
Далее при помощи групповой обработки справочников и документов перепроводим нужные документы. Если такой обработки нет, то ее также недолго накидать. После перепроводки у нас в плане обмена зарегистрируются нужные изменения. Причем нам не надо переживать за ссылочную целостность. Мы работаем в старой версии рабочей базы. Все справочники, на которые будут ссылаться передаваемые объекты в любом случае есть в рабочей базе.
Далее надо настроить обмен по выбранному узлу на обмен через локальный ресурс, и отключить сжатие исходящих сообщений. В УТ 2.3 это настраивается так:
В указанной папке мы получаем файл xml с наименованием, наподобие Message_Цнт_К2.xml. После первого подчеркивания идет код базы отправителя, после второго — код получателя. Переименовываем файл в Message_К2_Цнт.xml. Таким образом механизм РИБ будет считывать этот файл как сообщение от периферийной базы. Но это еще не все. Открываем этот файл при помощи текстового редактора и вносим правки:
Атрибут v8msg:To — код узла получателя, v8msg:From — код узла отправителя. Меняем значения в них местами.
Атрибут v8msg:MessageNo — номер отправленного сообщения, v8msg:ReceivedNo — номер полученного сообщения. Меняем номер отправленного сообщения. Он должен быть больше номера полученного сообщения, чтобы механизм РИБ загрузил изменения из этого файла. Можно поставить заведомо большое число, например 99999. Главное запомнить, какой номер принятого был до этого.
Если попытаться скормить полученный файл базе, то получим ошибку. Точный текст не помню, но что-то вроде "Ошибка представления". Путем сравнения файлов сообщений от центральной базы и от периферийной было определено, что узел v8de:Nodes отсутствует в сообщении от периферийной базы. Удаляем этот узел из файла сообщения.