Можно организовать автоматическое принятие конфигурации центральной базой (сделав ее таким образом практически необслуживаемой).
Для этого - ручками добавить измененный MD в файл обмена, сгенерированный одной из периферийных баз. Тогда ЦБ молча принимает измененную конфигурацию (как и любая периферийная в той же ситуации) и раздаст эту конфигурацию всем периферийным ( как это положено ЦБ при изменении конфигурации).
Правда, если принятие конфигурации невозможно (из-за ограничений ссылочной целостности, например) - то его и не произойдет.

При этом надо позаботиться, чтобы в файле обмена не было одновременно нового MD и данных старой структуры - потому что вначале всегда выполняется реструктуризация, а потом принятие данных.
Лучше, если это будет не эксплуатируемая обычными пользователями база (только получатель).
Тогда добавление МД в архив вполне автоматизируемо.

Альтернатива - слегка обманывать периферийную базу, чтобы она приняла новый МД и реструктурировалась перед формированием файла обмена для ЦБ.

Разумеется, что никакие ухищрения не помогут принятию новой конфигурации в ЦБ без монопольного доступа Конфигуратора к базе.

PaulWist
Правильно ли я понимаю, что надо самостоятельно создать *.zip файл который УРИБ формирует для передачи в цент, для этого надо наряду с самими данными так же добавить конфигуратор (кстати какие именно файлы должны быть добавлены)?

pail
При этом надо позаботиться, чтобы в файле обмена не было одновременно нового MD и данных старой структуры - потому что вначале всегда выполняется реструктуризация, а потом принятие данных.


Понятно, поясните в каком случае возможно такое совмещение?

pail
Альтернатива - слегка обманывать периферийную базу, чтобы она приняла новый МД и реструктурировалась перед формированием файла обмена для ЦБ.


Вот это не понял, как это технически выполнить? Догадываюсь, что надо манипулировать файлами 1sdbset, 1ssystem.

1. надо добавить в zip, сформированный штатно Конфигуратором, 1cv7.md с измененной конфигурацией.

2. Если в новом MD изменены какие-то структуры БД , что приведет к реструктурированию неких таблиц, и в файле обмена присутствуют данные того же (подлежащего реструктурированию) типа.

3. Манипулировать достаточно единственным файлом - 1sdbset.
Достаточно поменять содержимое одного поля (статус базы) в двух его записях (или вообще в одной - не помню точно за давностью практики) , чтобы:
- база стала считать себя Центральной
- корректно пометила для отправки все, что изменено, для отправки настоящей ЦБ
В таком состоянии можно свободно и долго работать. Можно даже конфигурацию править (если есть уверенность, что эти изменения в ЦБ приняты БУДУТ).

Только перед формированием файла обмена надо назад вернуть оригинальное состояние файла.

Маркер изменения конфигурации в 1supdts будет - не уверен только, что та попадет в выгрузку от ПБ к ЦБ. Проверить надо, и добавить при необходимости, а то ошибка при приеме выйдет....