Как бороться с сообщением "Изменения конфигурации не загружались в ИБ из которой пришел файл переноса"

1) Делаем выгрузку из ПБ;
2) Изменяем конфу в ЦБ и пытаемся загрузить выгрузку -> получаем: “Изменения конфигурации не загружались в ИБ из которой пришел файл переноса”;
3) Делаем выгрузку из ЦБ. Обязательно загружаем этот архив на ПБ, иначе часть документов из ЦБ не выгрузится в ПБ;
4) Просмотрщиком открываем файл 1Cv77Dld.id (выгрузки ЦБ) и наблюдаем строчку похожую на:
{“Download ID”,B32CA7C5-4FC6-431D-ABF8-2A5E6F7658F9,“KL”,3BB40AD2-5DDA-4E39-83BB-ADB5C65A081F,“ЦБ”,8BAA3284-2B8C-450E-868F-781896A54BC4,“9|KL”}
(ага! запоминаем цифру 9);
5) Распаковываем файл 1Cv77Chs.dat, прибывший из ПБ;
6) Ищем строчку похожую на {“8|ЦБ”}} (за ключевым словом Acknowledgements, у меня 4-я сверху);
7) Меняем 8 на 9 и запаковываем обратно;
8) Теперь в ЦБ все замечательно загружается!
Подводя итоги:
1) Номер выгрузки из ЦБ в файле 1Cv77Dld.id всегда должен соответствовать номеру выгрузки из ПБ в файле 1Cv77Chs.dat.
2) ВНИМАНИЕ!!! Такой фокус не рекомендуется проделывать при структурных изменениях конфигурации!

И не забываем про бэкапы!!!

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

Подробности.
Когда в базе изменяется подлежащий обмену объект, в таблицу(файл) 1SUPDTS(?) пишется строчка. В ней указывается код типа объекта, код объекта, код базы-получателя.
При формировании выгрузки для какой-либо базы файлу присваивается порядковый номер, в него выгружаются объекты, для этой базы предназначенные, а в соответствующие строки 1SUPDTS вписывается номер выгрузки. Удалены эти строки будут только тогда, когда придет подтверждение (Acknowledgements) с этим самым номером.
Если выгрузить повторно - выгрузка будет со следующим номером, в строки таблицы будет записан уже новый номер, и система будет ждать подтверждения.
* Следствие. Если выгрузка идет систематически, а размер файла настойчиво растет даже при уменьшающейся интенсивности работы - это может означать, что подтверждения не приходят, что-то не так на той стороне.

Ценность УРБД - в простоте, тут просто ломаться нечему

Хм... тема актуальна? Тогда, наверное, есть смысл вспомнить подводные камни.
Возможно, что-то из этого списка исправлено в последних платформах, а может и нет - 1с8 тогда уже продавалась...

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

2. Если у вас под УРБД работает ЗиК, комплексная с включенным участком Зарплата или любая другая с использованием ЖурналаРасчетов, то нужно любыми средствами запретить проведение зарплатных документов в "неродной" базе. Если при проведении такого "чужого" документа в ЖР будет записан хотя бы одна запись сверх их исходного количества - очень скоро обмен станет колом.
Запись ЖР - самостоятельный объект конфигурации, но его код при создании формируется на основе кода документа, а не кода текущей базы. То есть код у Записи такой, как если бы она была создана в месте создания документа. А в это же время в базе, из которой мигрировал документ, нумерация Записей продолжается своим чередом... Сможет "левая" запись (по времени и настройкам миграции) попасть в Место создания документа - никто ничего не заметит. Не успеет - "дубль в ключевом поле".

3. Не пытайтесь делать выгрузку/загрузку по сети. Это выглядит удобным и изящным, но - лотерея. Не поленитесь, пропишите: выгрузка на диск размещения каталога базы, копирование файла на диск размещения другой базы, затем загрузка в той базе "из под себя". Да, придется создавать отдельное задание на каждом сервере и сдвигать их по времени. Это лучше, чем нестись сломя голову в филиал из-за остановки обмена.


Господа, подключайтесь, продолжайте!

Блин, только сейчас заметил, что у автора той ветки файлы MD идентичны Исправляюсь

Для этого случая есть кардинальное решение(годится только для баз с идентичными MD!!!).

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

2. Берем любой DBFEditor (Эксель не поможет!) и лезем в файл 1SUPDTS.dbf.
Для SQL - SQL Server Management Studio, таблица 1SUPDTS.

3. В таблице/файле находим все строки со следующими значениями полей:
DBSIGN (Код базы УРБД) - Код нашей периферийной базы
OBJID (Идентификатор объекта ИБ) - пусто (0)
Эти строки создаются при сохранении измененной конфигурации. Строки с различными TYPEID указывают на изменение отдельных объектов конфигурации.

4. Аккуратно удаляем все эти строки, сохраняем и закрываем файл(закрываем таблицу). Теперь и ЦБ считает, что конфигурации идентичны.
! Если случайно удалили строку с заполненным OBJID - все закрываем, восстанавливаем базу из бэкапа и начинаем все сначала. Это было изменение какого-то очень важного документа

5. Можно запускать обмен и работать.

Сделал успешно по такой инструкции:


Чтобы превратить распределенную базу в обычную, удалите файлы 1SDBSET.DBF, 1SDWNLDS.DBF, 1SUPDTS.DBF и соответствующие им файлы *.CDX, а также 1SSYSTEM.DBF. В принципе, достаточно удалить 1SSYSTEM.DBF. После этого необходимо восстановить точку актуальности, запустив программу в монопольном режиме. Этот трюк недокументирован (угадайте, почему), но, тем не менее, он работает.
За работу компоненты УРБД отвечает библиотека DistrDB.dll в папке BIN программы 1С:Предприятие. Эта компонента приобретается и устанавливается отдельно... создать такой пустой файл, потом запустить инсталяцию снова, файл сделается

Согласно документации, процесс инициализации РБД - необратимый, но иногда возникает потребность удалить всякое упоминание о том, что база данных когда-то была распределенной.Что для этого необходимо сделать:
В первую очередь, в файле 1SSYSTEM.DBF вручную очистить 3-х символьное поле DBSIGN (содержащее код ИБ), и, в принципе, этого достаточно.
Для возврата ИБ в первозданное состояние нужно дополнительно:
Удалить файлы 1SDBSET.DBF, 1SDWNLDS.DBF, 1SUPDTS.DBF и соответствующие индексные файлы (.CDX) .
В файле 1SSYSTEM.DBF обнулить 36-ти символьную строку DBSETUUID: 00000000-0000-0000- 0000-000000000000.

"В таблице _1SDBSET есть поле DBSTATUS, оно может принимать следующие значения:
P - Центральная
M - Текущая
N - Периферийная (непроинициирована)
C - Периферийная
В периферийной базе меняешь эту таблицу соответствущим образом и все Ок."

Если забыл выгрузить изменения из централ. в периф.:

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

1) Делаем выгрузку из ПБ скуль в дбф;
2) Изменяем конфу в ЦБ и пытаемся загрузить выгрузку -> получаем: "Изменения конфигурации не загружались в ИБ из которой пришел файл переноса";
3) Делаем выгрузку из ЦБ;
4) Просмотрщиком открываем файл 1Cv77Dld.id (выгрузки ЦБ) и наблюдаем строчку похожую на:
{"Download
ID",B32CA7C5-4FC6-431D-ABF8-2A5E6F7658F9,"KL",3BB40AD2-5DDA-4E39-83BB-ADB5C65A081F,"ЦБ",8BAA3284-2B8C-450E-868F-781896A54BC4,"9|KL"}
(ага! запоминаем цифру 9);
5) Распаковываем файл 1Cv77Chs.dat, прибывший из ПБ;
6) Ищем строчку похожую на {"8|ЦБ...}} (3-тья строка)
7) Меняем 8 на 9 и запаковываем обратно.


тобто далі (після виділеного) так як в топік стартері

ЦБ на SQl 2000 крутилась, ПБ - на dbf.

так не получилось

работает

Ну и, на мой взгляд, - самый "легальный" способ:

1) Изменяем конфигурацию ЦБ. Так что бы была реструктуризация данных. (новый справочник или документ или реквизит).
2) Обмениваемся
3) Вернуть конфигурацию в состояние до пункта 1.

Всем откликнувшимся БОЛЬШОЕ СПАСИБО.