С появлением режима совместимости 8.3.12, как вы знаете, появилась возможность распространять расширения из центрального узла в подчиненные вместе с обменом. Будем считать, что план обмена и конфигурация у вас поддерживает передачу расширений в узлы (подробнее по настройке вы можете посмотреть, например, тут).
Казалось бы, после этого достаточно просто добавить расширение в центральный узел, установить ему признак "Используется в РИБ", выполнить обмен и принять расширение в узле! Но реальность оказалась куда "интереснее".
Идентификаторы объектов расширений
Первая проблема, с которой вы можете столкнуться в центральном узле (при использовании типовой конфигурации) при выгрузке — это возможное отсутствие записей в справочнике "Идентификаторы объектов расширений", если в расширение вы добавили новые объекты (справочники, регистры сведений и т.д.). В этом случае можно выполнить обновление справочника процедурой:
ЕстьОбновления = Ложь;
ЕстьУдаленные = Ложь;
Справочники.ИдентификаторыОбъектовРасширений.ОбновитьДанныеСправочника(ЕстьОбновления, ЕстьУдаленные, Ложь);
К статье прикрепил готовую обработку с одной кнопкой, которая запускает выполнение этой процедуры:
Нарушение прав доступа, файл не обнаружен ParamsDBNames…
Еще одна проблема, которая может изрядно испугать рядового пользователя. Не всегда, но возникает после подключения расширения, в котором добавлены новые объекты. Пользователи даже с полным правами не могут войти в 1С, хотя вы уверены, что на свои объекты вы дали права, либо чтение/запись производится в привилегированном режиме. И вообще, почему он ругается на таблицу, явно связанную с новым добавленным объектом? При этом утилита chdbfl проблем не обнаружила, да и ТиИ результатов не дало. И вот тут стоит вспомнить шутку о том, что
В любой непонятной ситуации — чисти кэш!
Да, это именно тот случай: чистим кэш и прощаемся с проблемой!
Ошибка получения данных в узле (файловая база)
Итак, расширение в центре подключили, сделали выгрузку: осталось получить данные в узле! Да проще простого! Запускаем обмен и видим следующую картину:
Ага, думаем, расширение пришло и 1С просит перезапустить сеанс! Но после перезапуска расширение не работает, а обмен так и не идет. Ладно, смотрим ЖР:
Как так? Сеанс всего один и именно из него мы пытаемся выполнить обмен! Как еще можно это сделать? Ок, дождемся запуска обмена по расписанию. Ничего не поменялось?! Ну тогда чистим кэш, делаем тестирование… Ошибок при тестировании никаких, кэш почистили, но обмен так и не идет! После чтения ИТС, списка изменений в релизах платформ, экспериментов выяснилось, что все дело в платформе! После перебора версий выяснилось, что ошибка точно присутствует в версиях 8.3.13.1690 и 8.3.14.1565, а на версии 8.3.13.1513 обмен проходит без проблем. При этом, если на узле используется клиент-серверный вариант работы, то ошибка не воспроизводится. Опять-таки, в ходе экспериментов выяснилось: первый обмен следует запускать кнопкой "Выполнить сценарий" в форме настройки сценариев обмена; причем обмен удивительным образом проходит даже на проблемных версиях платформы! Почему таким образом удается провести обмен — пока непонятно. Стоит отметить, что в центре можно использовать любую платформу: ошибок с обменом в центральном узле не обнаружили.
Напоследок
Как выяснилось позже, если у расширения стоит признак "Используется в РИБ", то оно попадает в файл обмена при каждой выгрузке! Да, даже если вы не вносили изменений в расширение, оно все равно будет каждый раз выгружаться в узел! Так что если у вас проблемы с интернетом на точках, то самое время заняться оптимизацией состава расширения!
Следует помнить: если вы добавили новые объекты в расширении, у вас настроен РИБ через план обмена, который поддерживает передачу расширений в узлы, то обмен у вас не заработает до тех пор, пока вы у расширения не поставите признак "Используется в РИБ"!
А если вы еще не перешли на режим совместимости 8.3.12+?
В этом случае рекомендую ознакомиться со смежной статьей Расширения конфигурации и РИБ, друзья или враги? Или как мы передаем расширения подчиненным РИБ узлам
Надеюсь, данная статья поможет вам сэкономить массу времени нервов! Буду рад дополнить статью также вашими замечаниями, инструкциями и "находками" по данной теме!
Тестирование выполнялось на конфигурации 1С:Розница 2.2.11.29 и платформах 8.3.13.153, 8.3.13.1690 и 8.3.14.1565
Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
Спасибо, планировал поставить расширение в РИБ, теперь буду тестить.
Может в таком случае, отключать этот признак в общем случае РИБа, а когда будут внесены изменения в расширение, тогда и включать?
(2) надо пробовать. Не уверен, что после снятия галки обмен не удалит расширение в узлах. Но если в расширении добавлены свои объекты, то без галки обмен вообще не пойдет.
Если кому будет интересно решение проблемы «Расширение и РИБ» до 8.3.12, . Что касается полной передачи расширения в РИБ, это и ожидалось, там просто иного не предусмотрено, ровно как и в моём решении. И да, исправьте битую ссылку
(4) Спасибо! Ссылку поправил: кириллицу в адресе обрубил редактор.
Ну можно же было сделать проверку по контрольной сумме: поменялась — выгружаем. Думаю, это дело времени
(5)А от куда главная база узнает контрольную сумму? Хотя конечно можно было сделать, как я предлагал в своей статье, это при выгрузке в центральную базу, добавлять хеш-сумму расширение, а от неё бы уже центральная база проверяла и узнавала, надо менять расширение или нет. Но 1Сники видимо решили по проще сделать.
(6)
1С вроде сейчас так и делает. К сожалению, сейчас нет РИБ под рукой, но в XML был узел с именем «DigestExtension» или как-то так
(7) Тогда странно что каждый раз выгружает. В моём кстати решении, там на сервер передается хеш сумма расширения и сервер тем самым узнает что надо передавать расширение клиенту или нет. Но вот разностная выгрузка средствами языка к сожалению не возможна.
(8) да с разностной выгрузкой ладно, в большинстве случаев расширение не так много весит. Надо будет повнимательней последить за хэшем расширения в файле обмена.
(3)
Имеется в виду ссылочные объекты?
У меня в расширении есть добавленные объекты (формы), признак использования РИБ отключен, синхронизация выполняется. Расширения в узлах обновляю вручную.
(10) грубо говоря, которые изменяют состав таблиц ИБ (справочники, регистры сведений, реквизиты справочников и т.д.). В этом случае, если расширение добавлено в центре, то структура ИБ центрального узла будет отличаться от структуры узлов, что приведет к рассогласованности данных. Добавленная форма — это всего лишь способ вывода информации для пользователя, поэтому такое расширение может применяться как с галкой «Используется в РИБ», так и без нее
(9) Я как то анализировал эти хеши. Была ситуация, когда хеш расширения в центральной базе не совпадал с хешем расширения в периферийной базе. Это получилось из-за того, что некий узел конфигурации-расширения из центральной базы не передавался в периферийную. Возможно этот узел использовался в предыдущих версиях платформы, а в новой версии про него забыли и он просто лежит там как мусор. Если взять расширение из периферийной базы и загрузить в центральную, то хеши расширений начинают совпадать. Я надеялся, что после совпадения хешей расширение конфигурации перестанет каждый раз передаваться в периферийную базу, но оно всё равно передаётся. Ну хоть работает, уже хорошо.
Большое вам человеческое СПАСИБО! Предлагаю сделать свой bugboard платформы 1С на инфостарте. Каждое обновление платформы как игра в рулетку или взлетит или нет(
(13) зачем плодить сущности?
От этого будут быстрее ошибки исправлять?
(14)Следуя вашей логике получается и инфостарт всего лишь дубль сущности stackoverflow? Или вы никогда не сталкивались с ошибками платформы при обновлении, которых нет на bugboard.v8.1c.ru? Ждать когда вендор исправит ошибку можно очень долго), и только сообщество разработчиков 1С на просторах рунета зачастую может помочь одинокому 1С-нику в дальних уголках нашей необъятной Родины)
8.3.13.1644
Ставлю признак «Используется в РИБ», при попытке обмена ошибка в ЦУ:
Ошибка записи данных в файл сообщения обмена: {Обработка.КонвертацияОбъектовРаспределенныхИнформационныхБаз.МодульОбъекта(270)}: Ошибка при вызове метода контекста (ЗаписатьИзменения)
ПланыОбмена.ЗаписатьИзменения(ЗаписьСообщения, КоличествоЭлементовВТранзакции);
по причине:
В текущем сеансе существуют неактуальные расширения конфигурации, используемые в распределенной информационной базе.
Что с это значит?
(16) Похоже, что загрузили расширение в пользовательском режиме, но сеанс не перезапустили.
(17) Загружал в конфигураторе.
для чистоты: завершил все сеансы — удалил расширение в конфигураторе — перезапустил 1С — добавил расширение в конфигураторе с признаком «Используется в РИБ» — запускаю обмен в режиме предприятия — та же ошибка.
(18) та же история 8.3.13.1690, 8.3.14.1630
Работает через кнопку сценарий
(19) Через сценарий обмен так же не взлетает
По крайней мере в 8.3.13.1644 …
(20) Решилось удалением всех расширений в конфигураторе (установленных до обновления платформы) и добавлением их по новой. Обмен пошел сразу по кнопке Синхронизировать.
Решение подойдет в случае, если в расширениях нет собственных документов и справочников.
Всё это ерунда. Пока не исправят баг с платформой счастья в РИБ не ищи. Пляски с бубном помогают каждому по своему. У нас 2 сервера для 1) 8.3.14.1565 пока танцевали с бубном каким то чудесным образом из файлов обмена пропали данные по расширениям. Если раньше есть расширение в ЦБ, то в файле выгрузки идут строки
<v8de:ConfigurationExtension>
<v8de:Id>645b2314-4ade-11e9-8d9e-708bcda98ec4</v8de:Id>
<v8de:Name>ОстаткиИЦеныВПодборе</v8de:Name>
то сейчас их нет. И обмен идёт отлично. Как так получилось но я рад до следующего обновления платформы)
2) 8.3.14.1630 Здесь не помогло не чего. Так и делаем обмен через сценарий.
P.S. пока танцевал с бубоном заметил такую вещь.
Если ЦБ 8.3.14 а ПБ 8.3.13 обмен не идёт не при каких условиях, так как в файле обмена меняются строки
<v8de:Version>216.0</v8de:Version>
<v8de:Digest1>00000000000000000000000000000000</v8de:Digest1>
<v8de:Digest2 v2=»57881d97074ef04efe7be54c9c51d7d2″ Extensions=»0000000000000000000000000000000000000000″>9d1874
Где то на форуме многие страдали от этой проблемы. Может кому поможет.
8.3.14.1694 ошибка исправлена.
Это интересно, когда расширение передается из Центральной базы в распределенные(с признаком «Используется в РИБ»).
В моей ситуации расширение для каждой распределенной базе отдельно добавляется.
Ошибка аналогичная: «Ошибка чтения файла сообщения обмена: {Обработка.КонвертацияОбъектовРаспределенныхИнформационныхБаз.МодульОбъекта(200)}: Ошибка при вызове метода контекста (ПрочитатьИзменения): База данных заблокирована:»
Ошибка на платформе: «8.3.13.1865»
Розница: «2.2.11.24»
(23)Это проверенная опытным путем информация?)
На сайте багборда не нашел соответствующей инфы
(25) Да. У меня РИБ на 2х серверах на 8.3.14.1694 взлетел. На данный момент полёт нормальный. Уже даже обновил розницу до 2.2.12.хх
(24) Та же ошибка на рознице 2.2.12. 1С:Предприятие 8.3 (8.3.14.1565).
(27)
Попробуй
Напиши, потом, как дела с этой платформой у Тебя))
Да обновление платформы исправляет ситуацию, спасибо.
(29) обновление до 8.3.14.1694 помогло, верно?
(30) На 8.3.14.1779 точно осталась только проблема с первоначальной загрузкой расширения (либо при загрузке обновления расширения) — для решения см. пункт «Ошибка получения данных в узле»
(31) расширение передаешь из центральной базы в переферийные?
(32) да. При первой передаче или при изменениях расширения в центре — в узле изменения приходится принимать через кнопку «выполнить сценарий»; потом обмен проходит без проблем
(21)Платформа 8.3.13.1644
1. Подтверждаю, если в расширении не добавлены объекты из расширяемой конфигурации (или не добавлены новые объекты), то обмен работает по кнопке «Синхронизировать».
2. Подтверждаю, вывод статьи: если в расширении добавлены новые объекты метаданных, тогда первую синхронизацию с Узлами нужно делать по кнопке «Синхр. по сценарию», тогда расширение мигрирует в удаленную базу. После этого перезапускаем базу — чтобы принялись изменения расширения и снова жмем «Синхр. по сценарию» — в этот этап «подхватываются» уже данные. Да, если не перезапустить базу, то можно увидеть, вернее, не увидеть записи для заимственных в расширение объектов. При последующих синхронизаций, лучше синхронизировать «по сценарию», а то, вдруг обновление прилетит. Да и пользователей нужно учить, если синхронизация выполнена с ошибкой, пускай перезапускают базу и снова синхронизируются.
Как-то так.
(29) Обновил розницу до 2.2.12.30 версия платформы 8.3.13.1865 обмен на узле РИБ возможен только через кнопку «Выполнить сценарий» и когда в базе сидит один пользователь. Как только подключается второй пользователь сразу идет ошибка «База данных заблокирована» Помогает обновление платформы решить данную ошибку?
(35) к базе подключаются два пользователя на одном компьютере
(36)
Платформа 8.3.14.1630, Розница 2.2.13.12, файловая периферийная — та же ерунда. Обмен работает только если вручную нажать «Выполнить сценарий». В центральной все ОК.
(37) решил в правилах отключить передачу расширений в РИБ, проверил на тестах — обмен работает
(38) Так да, работает без проблем. А если в расширение добавить новые объекты (регистр, справочник и т.п.), то РИБ не будет работать со снятой галкой «Используется в РИБ» у такого расширения
(39) а других вариантов пока не вижу, к сожалению не всегда есть возможность сделать обмен что бы на периферийной базе работал один человек. Пока идет обмен, обычно еще и торговать надо.
(39) Именно так. Если в расширении есть новые объекты или изменены имеющиеся объекты на уровне данных, то расширение придется включать в обмен, без этого на периферийной базе не будут загружаться пакеты