Данные из указанного файла переноса данных уже загружались в текущую информационную базу
Vofka --> Vofka
Уххх, лет пять семерошную УРБД в руках не держал
Пункт 3 нужно обязательно выполнять, изгнав из базы всех пользователей. Собственно, такая ситуация и возникает из-за попытки загрузки изменений конфы в разделенном(немонопольном) режиме.
Ну а дальше можно не мудрствовать, а просто повторить выгрузку из ПБ. УРБД устроена таким образом, что потеря файла обмена приводит только к задержке по времени, данные будут выгружены в следующий раз.
Подробности.
Когда в базе изменяется подлежащий обмену объект, в таблицу(файл) 1SUPDTS(?) пишется строчка. В ней указывается код типа объекта, код объекта, код базы-получателя.
При формировании выгрузки для какой-либо базы файлу присваивается порядковый номер, в него выгружаются объекты, для этой базы предназначенные, а в соответствующие строки 1SUPDTS вписывается номер выгрузки. Удалены эти строки будут только тогда, когда придет подтверждение (Acknowledgements) с этим самым номером.
Если выгрузить повторно - выгрузка будет со следующим номером, в строки таблицы будет записан уже новый номер, и система будет ждать подтверждения.
* Следствие. Если выгрузка идет систематически, а размер файла настойчиво растет даже при уменьшающейся интенсивности работы - это может означать, что подтверждения не приходят, что-то не так на той стороне.
Ценность УРБД - в простоте, тут просто ломаться нечему
Zaval --> Zaval
Хм. тема актуальна? Тогда, наверное, есть смысл вспомнить подводные камни.
Возможно, что-то из этого списка исправлено в последних платформах, а может и нет - 1с8 тогда уже продавалась.
1. Не стОит использовать в кодах баз кириллицу. Поначалу все может идти нормально, а сюрпризы могут появиться в самый неподходящий момент.
Нпр, с одной базой нужно обмениваться каждый час, а с остальными - раз в день. Вполне логично создать два задания в шедулере и два файла параметров обмена, в одном из которых вместо * (обмен для всех баз) явно задать код. упс. тогдашняя платформа под Вин2000 просто не замечала этого кода, а коды без кириллицы отрабатывала на "ура".
2. Если у вас под УРБД работает ЗиК, комплексная с включенным участком Зарплата или любая другая с использованием ЖурналаРасчетов, то нужно любыми средствами запретить проведение зарплатных документов в "неродной" базе. Если при проведении такого "чужого" документа в ЖР будет записан хотя бы одна запись сверх их исходного количества - очень скоро обмен станет колом.
Запись ЖР - самостоятельный объект конфигурации, но его код при создании формируется на основе кода документа, а не кода текущей базы. То есть код у Записи такой, как если бы она была создана в месте создания документа. А в это же время в базе, из которой мигрировал документ, нумерация Записей продолжается своим чередом. Сможет "левая" запись (по времени и настройкам миграции) попасть в Место создания документа - никто ничего не заметит. Не успеет - "дубль в ключевом поле".
3. Не пытайтесь делать выгрузку/загрузку по сети. Это выглядит удобным и изящным, но - лотерея. Не поленитесь, пропишите: выгрузка на диск размещения каталога базы, копирование файла на диск размещения другой базы, затем загрузка в той базе "из под себя". Да, придется создавать отдельное задание на каждом сервере и сдвигать их по времени. Это лучше, чем нестись сломя голову в филиал из-за остановки обмена.
Zaval --> Zaval
Блин, только сейчас заметил, что у автора той ветки файлы MD идентичны Исправляюсь
1. Выгоняем пользователей. Сохраняем бэкап ЦБ. Все делается именно на ЦБ. закрываем Конфигуратор.
3. В таблице/файле находим все строки со следующими значениями полей:
DBSIGN (Код базы УРБД) - Код нашей периферийной базы
OBJID (Идентификатор объекта ИБ) - пусто (0)
Эти строки создаются при сохранении измененной конфигурации. Строки с различными TYPEID указывают на изменение отдельных объектов конфигурации.
5. Можно запускать обмен и работать.
mister-x --> mister-x
Сделал успешно по такой инструкции:
Чтобы превратить распределенную базу в обычную, удалите файлы 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 - Периферийная
В периферийной базе меняешь эту таблицу соответствущим образом и все Ок."
Если забыл выгрузить изменения из централ. в периф.:
Придется в переферийной сделать Такие же изменения чтобы бызы стали по стуктуре аналогичными. Затем по шагам:
Сделал успешно по такой инструкции:
Если забыл выгрузить изменения из централ. в периф.:
Придется в переферийной сделать Такие же изменения чтобы бызы стали по стуктуре аналогичными. Затем по шагам:
Читайте также: