Проблемы 1С Расширения и 1С РИБа:
При появлении расширения в 1С многие простые изменения в 1С стали реализовываться через них, очень удобная штука, конфигурация находится всегда на поддержке, что безусловный плюс. Также появилась возможность расширения передавать в РИБ в версии 1С 8.3.12, указав признак "Используется в РИБ".
Но многие предпочитают делать отдельное расширение для каждого РИБа свое. Когда 1-2 РИБа еще можно внести изменения в каждое расширение, а когда их 10-15-20, то неудобно и затратно по времени.
Почему делают так? Чтобы избежать ошибок передачи самого расширения и данных. т.к. если в расширении указан признак "Используется в РИБ", то это расширение выгружается ВСЕГДА в файл обмена для узла, при каждой выгрузке (каждые 15 минут как правило). Даже если конфигурация расширения не изменялась не как, оно все равно будет выгружаться в файл обмена для распределенного узла. Это важно понимать: чем больше расширений или чем толще само расширение, тем толще и файл обмена при каждом обмене. Что может тянуть за собой разного рода проблемы.
1. Справочник "Идентификаторы объектов расширений". Первая проблема, с которой можно столкнуться после добавления расширения в центральную базу, это то, что расширение не зарегистрируется в справочнике "Идентификаторы объектов расширений", и все добавляемые в расширение изменения и объекты справочники, документы, регистры и т.д. не будут добавляться в данный справочник.
По факту мы получаем, что расширение есть в РИБе с нашими изменениями и объектами (справочники, документы и т.д.) но оно не работает в распределенной базе, либо база выпадает в ошибку, непонятно вообще откуда взятую, ведь в главной базе все то же самое работает....
Для исправления данной ситуации необходимо выполнить обновление справочника "Идентификаторы объектов расширений", делается это с помощью простой обработки (обработка приложена).
По этой же причине иногда может не создаваться новая распределенная база для нового магазина, для этого требуется повторно обновить идентификаторы объектов.
2. При обмене в центральным узлом, возникает ошибка получения данных в узле. Такая ошибка, как правило, возникает при добавлении нового расширения, наша любимая фирма 1С этот баг так и не исправила, как он был с самого начала 8.3.12, так он и есть по текущую платформу 8.3.19.1264 (хотя, может, так и задумано).
После выгрузки данных из центрального узла, мы пытаемся принять данные в РИБе, в автоматическом режиме (при автообмене), либо в ручном по кнопке "Синхронизировать".
После чего получаем ошибку:
"Ошибка исключительной блокировки информационной базы
активные сеансы:
компьютер: RIB1"
Подразумевается что расширение принято, но не может быть установлено, т.к. мы находимся в 1С: Предприятие, и требуется монопольный режим, и начинаются танцы с бубном.
Закрываем 1С предприятие, заходим в 1С конфигуратор, расширения нет. Заходим в 1С предприятие, делаем обмен, получаем ту же ошибку, и все по новой. Замкнутый круг. Расширение не принимается, и обмен перестает работать.
Вот тут и заключается баг от фирмы 1С, после добавления нового расширения в центральный узел и выгрузки его в РИБ, первый обмен в распределенном узле необходимо сделать через "Сценарий обмена".
Для этого в синхронизации необходимо войти в меню "Еще-Сценарий синхронизации данных", и там нажать кнопку "Выполнить сценарий". Иногда также требуется отключить "Выгрузку" и оставить только сценарий "Загрузки", если это один и тот же сценарий.
При таком способе расширение ставиться корректно и нам стоит только перезапустить 1С Предприятие, чтобы принять изменения и сделать синхронизацию в штатном режиме (она пройдет без ошибок).
3. Важно следить за совместимостью конфигурации и расширения. Еще один немаловажный момент, необходимо просмотреть расширение после обновления конфигурации или 1С платформы, обновить объекты конфигурации расширения, заменить их, изменить процедуры, которые могли измениться в обновлении, переключить совместимость расширения, если совместимость конфигурации изменилась. При сохранении и проверки есть такой механизм, но он не всегда корректно может отработать.
Немного отступления, был случай, который выпил много крови. Обновляли базу УТ 11.4 до последнего релиза в связи с маркировкой, обновили платформу т.к. новая УТ 11.4 не работала на той платформе, обновили РИБы (3 штуки) саму базу данных 1С и платформу соответственно. В базе было 2 расширения с доработками под нужды компании. Все работало все рады.
Через пару месяцев потребовалось внести небольшое изменения в расширения, вносится изменения, после обновления, база крашится в дамп и перестает напрочь работать. В режим 1С Предприятие не пускает, в режим конфигуратора входит но при попытке открыть список расширения дамп.
Ошибок по журналу нет, тесты базы через конфигуратор или через утилиту chdbfl проходят без ошибок, кэш не помогает, удаление расширений не помогает. Было ясно одно, что проблема с расширением, т.е. все работает, пока не трогаем расширение (восстанавливали неоднократно базу, пока не нашли причину). А причина была проста... Совместимость конфигурации была намного выше совместимости расширения, плюс ко всему платформа уже была 8.3.19. И проблемы в работе не было, т.е. 1С не выдавала ошибок совместимости или еще что-то, пока не поменяли структуру расширения, и тогда 1с очнулась, что вы нам тут втюхиваете.... ушло 2 дня на поиски проблемы, а оказалось простая вещь.
Ложкой дегтя было еще и то, что просто совместимость не изменить, т.к. после сохранения база крашилась, пришлось откатываться по платформе и на платформе 8.3.16 изменять совместимость, и потом уже все остальное. После того, как указали правильную совместимость, обмены пошли в штатном режиме, и все работало корректно и дальше.
4. Удаление расширения в центральном узле и распределенных базах. Если необходимо удалить расширение из базы, которое используется в распределенных базах, то его необходимо:
- Отключить в центральной базе, после чего во всех РИБах принять это изменение, что оно отключено и больше не используется;
- После того как во всех РИБах оно будет отключено, его можно удалять из центрального узла.
Если отключить и удалить расширение из центрального узла, которое ранее использовалось в распределенных базах, без принятия изменений об отключении в РИБах. То эти расширения зависают в распределенных узлах и их нельзя ни отключить, ни удалить, т.к. они идут из центрального узла. В связи с чем синхронизация не проходит, т.к. состав расширений и конфигурации не соответствует центральному узлу.
В итоге получается, что в распределенной базе есть расширение, а в центральном узле его нет, и информация в распределенный узел не передана об его отключении.
Что необходимо делать в таком случае и как это исправить:
- Обязательно! Делаем копию БД (если что-то пойдет не так);
- Отключаем в распределенной базе центральный узел, это можно сделать с помощью обработки;
Также отключить подчиненный узел от главного узла можно с помощью параметра запуска конфигуратора /ResetMasterNode.
"C:\Program Files (x86)\1cv8\common\1cestart.exe" config /f "D:\1C\ПапкаБазы" /n администратор /p пароль /ResetMasterNode
Удаление расширений через командную строку
Для удаления всех расширений (файловый вариант):
"C:\Program Files\1cv8\common\1cestart.exe" DESIGNER /f "Полный_путь_к_базе" /N "Имя_пользователя" /P "Пароль_пользователя" /DeleteCfg -AllExtensions
Для удаления одного расширения по имени (файловый вариант):
"C:\Program Files\1cv8\common\1cestart.exe" DESIGNER /f "Полный_путь_к_базе" /N "Имя_пользователя" /P "Пароль_пользователя" /DeleteCfg -Extension "ИмяРасширения"
Для удаления одного расширения по имени (серверный вариант, SQL):
"C:\Program Files\1cv8\common\1cestart.exe" DESIGNER /S «ИмяСервера/ИмяИнформБазы» /N "Имя_пользователя" /P "Пароль_пользователя" /DeleteCfg -Extension "ИмяРасширения"
- После отключения узла заходим в конфигуратор и удаляем расширения, которых нет в центральной базе, и сохраняем базу;
- При первом входе в базу в режиме предприятия 1С спросит восстановить узел ВАЖНО его ВОССТАНОВИТЬ!!!;
- После чего синхронизация проходит в штатном режиме.
5. Другие проблемы с расширениями. Прочие проблемы с расширениями при обмене.
- Нет доступа к файлу (если ранее все работало)
- файл не обнаружен Params\DBNames... и т.д.
Такие ошибки как правило возникают из-за зависшего кэша, и исправляются чисткой 1с КЭШа: "C:\Users\User\AppData\Local\1C\".
6. Восстановление узла распределенной информационной базы (при изменении конфигурации). Бывает, при изменении конфигурации центрального узла и выгрузке в распределенную базу, после синхронизации 1С говорит, что было принято изменение и надо обновить 1С, после обновление. Делаем синхронизацию повторно и опять то же самое и так бесконечно, изменения не принимаются, чтобы вы ни пытались с распределенной базой сделать.
Для исправления данной ошибки требуется сделать следующие шаги:
- Обязательно! Делаем копию БД (если что-то пойдет не так);
- Выгружаем конфигурацию главного узла в файл *.cf в режиме конфигуратора.
- Отключаем в распределенной базе центральный узел, это можно сделать с помощью обработки;
Также отключить подчиненный узел от главного узла, можно с помощью параметра запуска конфигуратора /ResetMasterNode.
"C:\Program Files (x86)\1cv8\common\1cestart.exe" config /f "D:\1C\ПапкаБазы" /n администратор /p пароль /ResetMasterNode
Пример: "C:\Program Files (x86)\1cv8\8.3.19.1150\bin\1cv8.exe" config /ResetMasterNode
Также этот метод поможет вам если, при обновлении конфигурации были проблемы и ошибки и режим предприятия не работает или вылетает ошибка при синхронизации или обновлении.
- Загружаем конфигурацию главного узла из файла *.cf в подчиненный узел в режиме конфигуратора. Загружаем полной заменой "Загрузить конфигурацию из файла", не сравнить, объединить конфигурации;
- Сохраняем конфигурацию;
- При первом входе в базу в режиме предприятия 1С спросит восстановить узел ВАЖНО его ВОССТАНОВИТЬ!!! Либо восстановить главный узел можно с помощью обработки;
- После чего синхронизация проходит в штатном режиме.
После выполнения этих действий работоспособность распределенной информационной базы будет восстановлена.
Внимание! Важный момент на "19" платформе (8.3.19.1150, 8.3.19.1467) очень много проблем с расширениями их обновлениям и доработкой. В один прекрасный день после очередного изменения или доработки расширение, 1с начнет падать в дамп (ошибку), не давай обновить расширение. Лечится либо откатом на "18" платформу либо на "20", если такой возможности нет, выгружаете базу разворачивайте на другой платформе обновляете или исправляете расширение и грузите базу назад. 1С и само расширение работает нормально и после проделанной работы. Способ рабочий.
К статье прилагаются обработки, с помощью которых можно исправить проблемы с распределенными база 1С.
Надеюсь, описанный опыт кому-то поможет и сэкономит кучу времени по решению проблем, возникших в распределенных базах.
