Группа: Основатель
Сообщений: 13955
Из: Киев
Спасибо сказали: 4519 раз
Рейтинг: 3641.2
Как бороться с сообщением "Изменения конфигурации не загружались в ИБ из которой пришел файл переноса"
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) ВНИМАНИЕ!!! Такой фокус не рекомендуется проделывать при структурных изменениях конфигурации!
Группа: Местный
Сообщений: 1994
Из: Киева и окрестностей
Спасибо сказали: 406 раз
Рейтинг: 0
Уххх, лет пять семерошную УРБД в руках не держал Пункт 3 нужно обязательно выполнять, изгнав из базы всех пользователей. Собственно, такая ситуация и возникает из-за попытки загрузки изменений конфы в разделенном(немонопольном) режиме. Ну а дальше можно не мудрствовать, а просто повторить выгрузку из ПБ. УРБД устроена таким образом, что потеря файла обмена приводит только к задержке по времени, данные будут выгружены в следующий раз.
Подробности. Когда в базе изменяется подлежащий обмену объект, в таблицу(файл) 1SUPDTS(?) пишется строчка. В ней указывается код типа объекта, код объекта, код базы-получателя. При формировании выгрузки для какой-либо базы файлу присваивается порядковый номер, в него выгружаются объекты, для этой базы предназначенные, а в соответствующие строки 1SUPDTS вписывается номер выгрузки. Удалены эти строки будут только тогда, когда придет подтверждение (Acknowledgements) с этим самым номером. Если выгрузить повторно - выгрузка будет со следующим номером, в строки таблицы будет записан уже новый номер, и система будет ждать подтверждения. * Следствие. Если выгрузка идет систематически, а размер файла настойчиво растет даже при уменьшающейся интенсивности работы - это может означать, что подтверждения не приходят, что-то не так на той стороне.
Ценность УРБД - в простоте, тут просто ломаться нечему
Группа: Местный
Сообщений: 1994
Из: Киева и окрестностей
Спасибо сказали: 406 раз
Рейтинг: 0
Хм... тема актуальна? Тогда, наверное, есть смысл вспомнить подводные камни. Возможно, что-то из этого списка исправлено в последних платформах, а может и нет - 1с8 тогда уже продавалась...
1. Не стОит использовать в кодах баз кириллицу. Поначалу все может идти нормально, а сюрпризы могут появиться в самый неподходящий момент. Нпр, с одной базой нужно обмениваться каждый час, а с остальными - раз в день. Вполне логично создать два задания в шедулере и два файла параметров обмена, в одном из которых вместо * (обмен для всех баз) явно задать код... упс... тогдашняя платформа под Вин2000 просто не замечала этого кода, а коды без кириллицы отрабатывала на "ура".
2. Если у вас под УРБД работает ЗиК, комплексная с включенным участком Зарплата или любая другая с использованием ЖурналаРасчетов, то нужно любыми средствами запретить проведение зарплатных документов в "неродной" базе. Если при проведении такого "чужого" документа в ЖР будет записан хотя бы одна запись сверх их исходного количества - очень скоро обмен станет колом. Запись ЖР - самостоятельный объект конфигурации, но его код при создании формируется на основе кода документа, а не кода текущей базы. То есть код у Записи такой, как если бы она была создана в месте создания документа. А в это же время в базе, из которой мигрировал документ, нумерация Записей продолжается своим чередом... Сможет "левая" запись (по времени и настройкам миграции) попасть в Место создания документа - никто ничего не заметит. Не успеет - "дубль в ключевом поле".
3. Не пытайтесь делать выгрузку/загрузку по сети. Это выглядит удобным и изящным, но - лотерея. Не поленитесь, пропишите: выгрузка на диск размещения каталога базы, копирование файла на диск размещения другой базы, затем загрузка в той базе "из под себя". Да, придется создавать отдельное задание на каждом сервере и сдвигать их по времени. Это лучше, чем нестись сломя голову в филиал из-за остановки обмена.
Группа: Местный
Сообщений: 1994
Из: Киева и окрестностей
Спасибо сказали: 406 раз
Рейтинг: 0
Блин, только сейчас заметил, что у автора той ветки файлы MD идентичны Исправляюсь
Для этого случая есть кардинальное решение(годится только для баз с идентичными MD!!!).
1. Выгоняем пользователей. Сохраняем бэкап ЦБ. Все делается именно на ЦБ. закрываем Конфигуратор.
2. Берем любой DBFEditor (Эксель не поможет!) и лезем в файл 1SUPDTS.dbf. Для SQL - SQL Server Management Studio, таблица 1SUPDTS.
3. В таблице/файле находим все строки со следующими значениями полей: DBSIGN (Код базы УРБД) - Код нашей периферийной базы OBJID (Идентификатор объекта ИБ) - пусто (0) Эти строки создаются при сохранении измененной конфигурации. Строки с различными TYPEID указывают на изменение отдельных объектов конфигурации.
4. Аккуратно удаляем все эти строки, сохраняем и закрываем файл(закрываем таблицу). Теперь и ЦБ считает, что конфигурации идентичны. ! Если случайно удалили строку с заполненным OBJID - все закрываем, восстанавливаем базу из бэкапа и начинаем все сначала. Это было изменение какого-то очень важного документа
Как бороться с сообщением "Изменения конфигурации не загружались в ИБ из которой пришел файл переноса"
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) ВНИМАНИЕ!!! Такой фокус не рекомендуется проделывать при структурных изменениях конфигурации!
И не забываем про бэкапы!!!
Сделал успешно по такой инструкции:
Чтобы превратить распределенную базу в обычную, удалите файлы 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 и запаковываем обратно.
Цитата(mister-x @ 27.01.11, 13:22)
Сделал успешно по такой инструкции:
Если забыл выгрузить изменения из централ. в периф.:
Придется в переферийной сделать Такие же изменения чтобы бызы стали по стуктуре аналогичными. Затем по шагам:
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 и запаковываем обратно.
тобто далі (після виділеного) так як в топік стартері
Как бороться с сообщением "Изменения конфигурации не загружались в ИБ из которой пришел файл переноса"
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) ВНИМАНИЕ!!! Такой фокус не рекомендуется проделывать при структурных изменениях конфигурации!
И не забываем про бэкапы!!!
так не получилось
Никогда не бойся делать то, что не умеешь, помни - Ноев ковчег был построен любителем, профессионалы построили Титаник. ЗиУП
Блин, только сейчас заметил, что у автора той ветки файлы MD идентичны Исправляюсь
Для этого случая есть кардинальное решение(годится только для баз с идентичными MD!!!).
1. Выгоняем пользователей. Сохраняем бэкап ЦБ. Все делается именно на ЦБ. закрываем Конфигуратор.
2. Берем любой DBFEditor (Эксель не поможет!) и лезем в файл 1SUPDTS.dbf. Для SQL - SQL Server Management Studio, таблица 1SUPDTS.
3. В таблице/файле находим все строки со следующими значениями полей: DBSIGN (Код базы УРБД) - Код нашей периферийной базы OBJID (Идентификатор объекта ИБ) - пусто (0) Эти строки создаются при сохранении измененной конфигурации. Строки с различными TYPEID указывают на изменение отдельных объектов конфигурации.
4. Аккуратно удаляем все эти строки, сохраняем и закрываем файл(закрываем таблицу). Теперь и ЦБ считает, что конфигурации идентичны. ! Если случайно удалили строку с заполненным OBJID - все закрываем, восстанавливаем базу из бэкапа и начинаем все сначала. Это было изменение какого-то очень важного документа
5. Можно запускать обмен и работать.
работает
Никогда не бойся делать то, что не умеешь, помни - Ноев ковчег был построен любителем, профессионалы построили Титаник. ЗиУП
1) Изменяем конфигурацию ЦБ. Так что бы была реструктуризация данных. (новый справочник или документ или реквизит). 2) Обмениваемся 3) Вернуть конфигурацию в состояние до пункта 1.
Всем откликнувшимся БОЛЬШОЕ СПАСИБО.
Никогда не бойся делать то, что не умеешь, помни - Ноев ковчег был построен любителем, профессионалы построили Титаник. ЗиУП
1С Предприятие 8.3, 1С Предприятие 8.2, 1С Предприятие 8.1, 1С Предприятие 8.0, 1С Предприятие 7.7, Литература 1С, Общие вопросы по администрированию 1С, Методическая поддержка 1С - всё в одном месте: на Украинском 1С форуме!