1с урбд место создания дополнительно
Обновлено: 08.07.2024
Компонента УРБД (Управление распределенными базами данных) применяется для обмена информацией между двумя идентичными базами 1С. Если конфигурации разные, то применять ее также можно, об этом написано в другой статье. Для работы компоненты необходимо наличие файла DistrDB.dll в папке BIN программы 1С: Предприятие.
Рассмотрим действия по созданию распределенных баз данных. Например, у нас есть рабочая база в каталоге D:\base1. Требуется сделать ее центральной и создать периферийную базу.
1. Создаем каталог D:\base2 для периферийной базы.
2. В каталогах D:\base1 и D:\base2 создаем папки CP и PC (используем латинские буквы).
3. Запускаем конфигуратор центральной базы (D:\base1) и выбираем Меню - Администрирование - Распределенная ИБ - Управление.
4. Нажимаем кнопку "Центральная ИБ", в появившемся окне вводим код и наименование базы. Для кода лучше использовать цифры или латинские буквы. Вводим, например, 001 и "Центральная база", подтверждаем нажатием кнопки "ОК".
5. Нажимаем кнопку "Новая периф. ИБ" для того чтобы создать периферийную базу. Вводим для нее параметры: 002 и "Периферийная база 1".
6. Курсором выделяем базу "Периферийная база 1" и нажимаем кнопку «Настр. автообмена». В настройках меняем ручной режим на автоматический. Будьте внимательны, это важно.
7. Курсором выделяем базу "Периферийная база 1" и нажимаем кнопку «Выгрузить данные», затем кнопку "ОК". В результате выгрузки появится файл D:\base1\CP\020.zip.
8. Запускаем 1С в режиме конфигуратора, добавляем в окне запуска 1С новую базу "Периферийная база 1", указываем для нее ранее созданный каталог D:\base2.
9. Выбираем Меню - Администрирование – Распределенная ИБ – Управление. На заданный вопрос «Информационная база не обнаружена. Выполнить загрузку данных?» нажимаем кнопку "Да" и указываем имя файла "D:\base1\CP\020.zip", нажимаем кнопку "ОК". После окончания загрузки процесс создания периферийной базы можно считать законченным.
В статье и еще в одной приведены способы создания периферийной базы путем восстановления из бэкапа копии центральной базы либо приаттачивания файлов копии центральной базы для формата SQL и выполнения скрипта. Это будет полезно при больших объемах данных, когда выгрузки-загрузки растягиваются на часы или вообще нереальны.
Инструкция по обмену между распределенными базами с помощью компоненты УРБД (УРИБ)
Рассмотрим упрощенный пример, выполнять обмен будем вручную, запуская конфигуратор. Можно использовать пакетный режим конфигуратора, для доставки пакетов обмена можно использовать почту, ftp, автоматическое копирование файлов.
Для выполнения обмена необходимо выбирать Меню - Администрирование - Распределенная ИБ - Автообмен. Если обмен автоматический (см. пункт 6 предыдущей инструкции), то все у нас получится.
1. Итак, изменяем либо создаем какие-то объекты, которые мигрируют в периферийную базу. Правила миграции объектов задаются на вкладке "Миграция" в свойствах объекта (см. дерево объектов в конфигураторе).
2. Запускаем конфигуратор центральной базы, выбираем Меню - Администрирование - Распределенная ИБ - Автообмен, нажимаем кнопку "Выполнить".
3. Полученный файл D:\base1\CP\020.zip перемещаем в папку D:\base2\CP\
4. Изменяем какие-то объекты периферийной базе данных. Желательно не те, которые менялись до этого в центральной базе, т.к. центральная база имеет приоритет изменений объектов при обмене.
5. Запускаем конфигуратор периферийной базы, выбираем Меню - Администрирование - Распределенная ИБ - Автообмен, нажимаем кнопку "Выполнить".
6. В результате автообмена у нас должны появиться изменения, поступившие из центральной базы данных. Также у нас должен появиться файл для передачи в центральную базу D:\base2\PC\021.zip
7. Копируем файл D:\base2\PC\021.zip в папку D:\base1\PC
8. Повторяем пункт 2. В результате в центральной базе появятся изменения, поступившие из периферийной базы.
Итак, общий принцип обмена: попеременное выполнение автообмена с одновременным перемещением файлов (пакетов обмена) из папки PC одной базы в папку PC другой базы и из папки CP одной базы в папку CP другой базы.
Изменение конфигурации производится только в центральной базе. При изменении конфигурации необходимо проведение обмена в периферийных базах в монопольном режиме. Для успешной обработки пакетов из периферийных баз в центральной базе конфигурация должна быть загружена в периферийные базы. Если вы запутались - ничего страшного, отвергнутый центральной базой пакет выгрузится повторно.
Автор статьи - Виктор Сахнов (Asmody)
Сразу замечу, что все нижеследующее относится к релизу платформы 8.0.7.36 и выше.
Шаг 1. Создание плана обмена
Создаем в конфигурации план обмена. Называем его, например "РаспределеннаяБаза". Обязательно в
свойствах плана обмена ставим флажок "Распределенная информационная база".
На закладке "Прочее" по кнопке "Состав" определяем, какие объекты будут включаться в обмен. По
умолчанию можно включить все объекты ("Действия"-"Включить все"). Важным моментом является параметр
"Авторегистрация". В общем случае ее нужно разрешить для всех объектов.
Замечание: при добавлении новых объектов в конфигурацию, они не включаются в план обмена. Т.е. после
добавления объекта его необходимо добавить в состав плана обмена.
Если Вы хотите, чтобы некоторые объекты не участвовали в обмене, просто исключаете их из состава
плана обмена. Но тогда контроль ссылочной целостности остается целиком на вашей совести. Если, к
примеру, некий документ не включен в план обмена, а регистр, по которому он делает движения включен,
то в базе-приемнике вполне реально получить движения по регистру без документа-регистратора, что
согласитесь, не есть хорошо.
В принципе, этих действий достаточно, чтобы РБД заработала в "ручном" режиме. Для этого запускаем
Предприятие, открываем наш план обмена через меню "Операции". В плане обмена всегда присутствует
предопределенный узел "с точкой". Это описание текущего узла. Его нужно открыть и заполнить. В нашем
случае будут доступны поля "Код" и "Наименование". Присвоим нашему узлу код "AA" и назовем
"Центральная". Добавим в план обмена один узел. Присвоим ему код "ВВ" и назовем "Периферийная".
Теперь мы можем создать образ периферийной базы. Делается это нажатием кнопки "Создать начальный
образ". В списке узлов должна быть выбрана периферийная база. Образ базы создается в виде готовой ИБ
в каталоге или на сервере 1С:Предприятия. (в отличие от 7.7, где образ ИБ создавался как файл
выгрузки). Далее созданную базу можно перенести в нужное место, просто скопировав файлик 1CV8.1CD
(для файлового варианта), либо через Конфигуратор через выгрузку-загрузку данных.
Если Вы откроете план обмена в периферийной ИБ, то Вы увидите, что узлом "с точкой", т.е. текущим
узлом стал узел "Периферийная", а иконка у узла "Центральная" стала красного цвета, т.е. узел
"Центральная" является главным узлом по отношению к текущему.
Обмен в "ручном" режиме можно производить при помощи кнопок "Записать изменения" и "Прочитать
изменения". В первом случае будет предложено выбрать файл, куда изменения будут записаны, во втором
- файл, откуда изменения будут считаны. Обмен ведется в формате xml. Изменения записываются для
выбранного узла.
Шаг 2. Выгрузка изменений в XML-файл и отправка по электронной почте
Итак мы создали план обмена, создали периферийную ИБ и даже научились переносить данные между
базами. Теперь наша задача научить базы обмениваться по электронной почте.
Процедуру для работы с электронной почтой сделаем универсальной, т.е. сделаем возможным
использование как MAPI (отправка-получение через почтового клиента, например, MS Outlook), так и
прямое обращение к SMTP/POP3 серверам.
Добавим в конфигурацию несколько констант:
где-нибудь в общей форме обеспечиваем редактирование значений этих констант.
Добавим общий модуль, назовем его "рбРаспределеннаяБаза". В нем пишем:
Рекомендую в интерфейс добавить дополнительную панель, на одну из кнопок которой повесить вызов этой
процедуры. Теперь осталось запустить Предприятие, настроить электронный адрес периферийной ИБ,
поставить галку "Выполнять обмен", нажать на кнопку процедуры на панели и бежать получать почту для
указанного эл. адреса. Должно придти письмо с темой "1С:Обмен AA_BB" и вложенным файлом
"Message_AA_BB.xml".
Шаг 3. Получение обновлений по электронной почте и запись их в ИБ
Теперь займемся обратной процедурой: получение обновлений по электронной почте и запись их в ИБ.
В параметры сеанса добавим параметр "ИдетОбменРаспределеннойБазы" типа Булево. Ниже я объясню его
назначение.
Добавим в общий модуль рбРаспределеннаяБаза такую процедуру:
Теперь в интерфейсе на нашей панели добавляем еще одну кнопку, на которую вешаем вызов этой
процедуры. Запускаем Предприятие и наслаждаемся.
Почти все сделано, осталась малость: заставить наши процедуры выполняться в автоматическом режиме.
Шаг 4. Настройка автоматического обмена
Итак, мы почти вплотную приблизились к цели нашего повествования. Остался всего один шаг: запустить
выполнение процедур обмена в автоматическом режиме. Приступим.
Добавим константу ИнтервалАвтообменаРаспределеннойБазы типа Число(5,0).
В настройки пользователя добавим параметр ВыполнятьОбменРаспределенныхБаз. Для конфигурации
"Управление торговлей" это делается так:
* В план видов характеристик "НастройкиПользователей" добавим предопределенную
характеристику ВыполнятьОбменРаспределенныхБаз типа Булево.
* В форме элемента справочника "Пользователи" настраиваем изменение этого параметра (как это
сделать можно посмотреть в модуле формы, по аналогии с остальными параметрами).
В модуль рбРаспределеннаяБаза добавляем процедуру:
в модуль приложения:
в процедуру ПриНачалеРаботыСистемы() модуля приложения добавим такие строки:
(после подключения торгового оборудования)
.
Добавим на нашу панель еще пару кнопок для управления процессом: на одну вешаем процедуру
ПроверитьПодключениеАвтообмена(), на другую - ОтключитьАвтообмен()
Запускаем предприятие, настраиваем свойства пользователя и интервал автообмена и все!
Теперь при заходе в базу под этим-самым-настроенным пользователем будет запускаться обработчик
ожидания ВыполнитьАвтообмен(). Естественно, в периферийной базе тоже нужно настроить пользователя
для обмена.
Еще одно маленькое, но важное замечание:
1cv8.exe CONFIG /F<путь к ИБ> /N<Пользователь> /P<Пароль> /UpdateIBCfg
Есть возможность изменить место создания доукмента..
Ситуация такая, есть база без УРБД, в которой была создана новая переферийная база.
Определенные документы имеют миграцию - мето создания и центр.
Нужно у выборочных документов изменить место создания на новый филиал.
Можно-ли это сделать?
(1) Ну я тоже в общем-то боюсь этого.Интересно отзывы тех людей, которые это уже попробовали сделать.
(3) Наивный :-)
(4) Посмотри на IDDoc нужного документа и сравни его с настройками УРБД.
Ок, то, что можно сделать, я понял.
Осталось понять что именно нужно делать? :-)
+6 Только придёться предварительно проверить, нет ли доков с таким id в перефирийке + Прошерстить все таблички , где светится изменяемый документ и поменять там на новый
(0) Если не умеешь лучше и дешевле в новую залить те доки ктрые нужно перенсти и с ЦБ удалить их. разве что Перенести через обработки почти не возможно из-за объема или другой особенности.
А если такой вариант:
1. Устанавливаю полную миграцию.
2. Делаю выгрузку, возвращаю миграцию на место.
3. Продолжаю работать. Новый документы будут уже "ходить" по новым правилам.
То, что при первой выгрузке выгрузятся некоторое количество "чужих" документов я понимаю. Последствия этого я как-нибудь разрулю.
Если однократно - ходи на инфостарт, бери мою обработку и отправляй что угодно, куда угодно и когда угодно.
(14) Нет, мне нужно, чтобы эти документы впоследствии в филиале могли менять.
(0) делать так вообще нельзя.
Если изменишь коды в одной переф базе как это попадет в другую
базу. Ведь это уже будут другие объекты и получишь в лучшем случае задвоение
в самом худшем загубишь базу.
Сформулируй subj как нибудь по другому тогда может тебе можно будет помочь.
(например можно явно в документе справочнике создать реквизит и в нем
хранить место создания объекта)
(18) И что это даст?
Мне часть документов нужна, часть не нужна.
(19) Я буду сам сейчас создавать переферийную базу. Т.е. ее пока еще нету.
после "есть база без УРБД, в которой была создана новая переферийная база" очень много думал.
(21) Сделать можно абсолютно все, но не все штатно, а многое банально не нужно.
(16) в филиале их менять смогут (если ты, конечно, не запретишь спецом менять чужие документы), и они вполне нормально усвистят в центр. Но если их изменят в центре - в новфй филиал изменения не попадут.
--------
Сделай полные копии нужных документов в новом филиале, и удали старые документы.
-----
или объясни подробно и на примере - чего именно хочешь.
(21) как создашь перенеси в ПБ созданием новых, те доки что там типа нужны, старые удали через Удалить - удалятся и в ЦБ и в "старой" пб, после выгрузки (если есть немигрирующие ссылки=повторить процедуру еще раз, начиная с ПБ, до победы).
Обработок по переносу документов и справочников в идентичные базы = шо грязи.
Больше ничего менять не надо.
(26) не, когда назад на место создания, мигрировать перестанут, это если в них менять чего (хотя и зачем старое трогать-не ясно). А если после не трогать = то можно и быстрее.
(26) Да хез чего автору надо. Пусть на русском опишет.
зы. хочу на курсы телепатии.
(27) Да куда уж быстрее..
уйдет все. Или я чет не так понял?
С самого начала:
Есть база в которой сейчас нет ни одной переферийных баз.
Есть документы у которых миграция место создания и центр.
Требуется создать переферийную базу, в которую должна будет перейти только часть документов.
Вариант:
1. Устанавливаю у требуемых документов полную миграцию.
2. Создаю новую переферийку.
3. Делаю выгрузку, возвращаю миграцию на место.
4. В переферийной базе удалаю ненужные документы пришедшие из центра, выключив регистрацию изменений.
4. Продолжаю работать. Новые документы будут уже "ходить" по новым правилам.
(30) что есть "часть документов"? произвольные документиы по произвольным критериям? Реализации, созданные в четверг при условии, что перед их созданием шел дождь? каждый третий четный документ, начиная с восьмого при переводе номера документа в 36-ричную систему?
(32) а будешь мистеть на приличных людей - пусть тебе (3) помогает.
(20) В этом файле храниться список изменены объектов. Соответственно, если после удаления документов грохнуть этот файл, то 1С неоткуда будет брать информацию об измененных/удаленных объектов и поэтому в центр ничего не уйдет
Это скорее всего и имеет ввиду (1) Т.е. манипулируя записями в этом файле можно рулть обменами как хочешь (жаль, что реквизиты нельзя изменить).
(30) База на скуле или дбф?
(37) Топорной, но эффективный
(37) Т.е. там где тупые грохнут файлик за 2 секунды, умный будет полдня писать и отлаживать код? И кто после этого тупой?
(39) В чем его тупость? Он позволяет решить данную задачу - да
(30) Все делаешь в воскресекнье когда с базой никто не работает.
1.Есть оригинальная база.
9. имеешь то что написано в (30).
(42) Суровые челябинские программисты против п.7 :)
(43) А по делу есть что возразить?
Всем спасибо, вроде получается как я написал в (30).
Пока еще не удаляли ненужные документы, но есть вероятность что это вообще не понадобится. :-)
(34) Часть документов - имеется ввиду документы определенного вида, отобранные по определенный правилам. В нашем обсуждении тонкости отбора документов не важны..
У нас есть центральная база с кодом 000, периферийная база с кодом 001. Требуется быстро создать новую периферийную базу.
Как из периферийной базы сделать центральную?
Вы также сможете это сделать после прочтения статьи, действуя по аналогии. Дополнительно понадобится список всех баз с их уникальными идентификаторами для заполнения таблицы _1SDBSET.
Структура таблицы _1SDBSET и признаки баз описаны в статье.
Итак, заходим в SQL Server Management Studio и видим содержимое двух служебных таблиц: _1SSYSTEM и _1SDBSET. В дальнейшем все действия будем производить только с ними.
Далее открываем Конфигуратор, заходим в Меню - Администрирование - Распределенная ИБ - Управление и создаем новую периферийную базу. На этом действия в 1С заканчиваются. Выгрузка и загрузка больших баз штатными методами часто нереальна.
Вот такую картину можно наблюдать в служебных таблицах 1С.
База имеет статус новой, поскольку выгрузка данных не производилась. Исправим это, выполнив запрос
UPDATE _1SDBSET SET DBSTATUS = 'C' WHERE DBSIGN = '002'
В результате таблицы примут вид:
А если открыть заново управление распределенными базами, то можно заметить, что база стала рабочей:
Теперь средствами SQL Server делаем бэкап базы и восстанавливаем его в новую базу (либо отсоединяем-копируем-присоединяем файлы базы данных SQL Server), т. е. создаем новую центральную базу. А текущую базу будем превращать в периферийную с кодом 002.
Выполняем запрос для изменения таблицы _1SSYSTEM.
UPDATE _1SSYSTEM SET DBSIGN = '002'
Изменяем статус центральной базы.
UPDATE _1SDBSET SET DBSTATUS = 'P' WHERE DBSIGN = '000'
Изменяем статус текущей периферийной базы.
UPDATE _1SDBSET SET DBSTATUS = 'M' WHERE DBSIGN = '002'
Удаляем данные о лишних базах.
DELETE FROM _1SDBSET WHERE DBSTATUS = 'C'
В случае превращения периферийной базы в центральную нам придется наоборот добавлять сведения по недостающим базам и иначе менять признаки баз.
На этом работа закончена. Можно обмениваться данными.
Если есть объекты, которые мигрируют по правилам "Место создания - Центр", то в текущей базе окажутся данные, созданные в других периферийных базах. Если это критично - можно скриптами удалить такие объекты.
Читайте также: