В практике администраторов и программистов 1С нередко возникают ситуации, когда база данных подчиненного узла распределенной информационной базы (УРИБ) выходит из строя. Проблема осложняется тем, что при повреждении ключевых данных (например, таблиц констант или модулей) система может блокировать вход даже в режиме Конфигуратора. Поскольку база является подчиненным узлом, внесение изменений в конфигурацию заблокировано, что делает стандартные методы "лечения" недоступными. Разберем подробно, как перевести такую базу в автономный режим, сняв её с поддержки центрального узла.
Самый простой и правильный способ, предусмотренный платформой 1С, — это использование специального параметра командной строки при запуске Конфигуратора. Этот ключ принудительно очищает информацию о главном узле в базе данных. Рассмотрим, как правильно сформировать строку запуска.
Проанализируем типовую команду для выполнения этой операции. Важно учитывать путь к исполняемому файлу вашей версии платформы:
"C:\Program Files (x86)\1cv8\8.3.X.XXXX\bin\1cv8.exe" CONFIG /F "C:\PathToYourBase" /N "Admin" /P "Password" /ResetMasterNode
Разберем ключевые параметры этой строки:
/S с указанием сервера и имени базы.Важный нюанс: если при использовании этого ключа система выдает ошибку аутентификации, хотя логин и пароль верны, это может свидетельствовать о повреждении таблицы пользователей или блокировке входа на уровне модуля сеанса. В таком случае перейдем к следующим методам.
Если база данных работает под управлением MS SQL Server или другой СУБД, мы можем напрямую воздействовать на системную таблицу Params, где хранится запись о главном узле. Это позволит нам снять ограничения, даже не запуская конфигуратор.
Выясним причину блокировки: система ищет в таблице Params запись с идентификатором masterNode. Если мы удалим эту запись, база перестанет считать себя подчиненной. Рассмотрим порядок действий:
Params в вашей базе данных.
SELECT * FROM Params WHERE FileName = 'masterNode'
DELETE FROM Params WHERE FileName = 'masterNode'
После выполнения этой операции база станет автономной. Теперь мы можем зайти в Конфигуратор, внести необходимые изменения в программный код или структуру данных, чтобы исправить ошибки, которые мешали запуску.
Для файловых баз ситуация сложнее, так как напрямую SQL-запрос выполнить нельзя. Однако мы можем воспользоваться специализированными утилитами для просмотра и редактирования таблиц файлов .1CD (например, Tool1CD). Рассмотрим этот процесс по шагам:
Во-первых, обязательно сделайте резервную копию файла базы данных. Любое прямое редактирование структуры файла несет риски полной потери данных. Далее откройте файл базы в утилите и найдите таблицу Params. По аналогии с SQL-версией, нам необходимо найти строку, где поле FileName содержит значение masterNode, и удалить эту строку целиком.
После сохранения изменений база должна открыться в обычном режиме без ограничений, накладываемых распределенной базой.
Часто при повреждении базы данных повреждаются и механизмы проверки прав доступа. Если ключ /ResetMasterNode не срабатывает из-за ошибки аутентификации, нам нужно временно "обнулить" пользователей. Разберем, как это сделать.
В файловой версии достаточно временно переместить или переименовать файл 1Cv8.users, который находится в подпапке 1Cv8Log или в корне каталога базы (в зависимости от версии платформы). Однако в современных версиях 8.3 пользователи хранятся внутри файла базы. В этом случае для клиент-серверной версии можно очистить таблицу v8users и запись users.usr в таблице Params.
После очистки этих таблиц вы сможете зайти в базу под пустым пользователем с полными правами, выполнить команду /ResetMasterNode или произвести исправление данных через тестирование и исправление.
Если проблема вызвана физическим повреждением структуры файла (например, когда "битыми" оказываются константы, на которые ссылается модуль сеанса), необходимо сначала восстановить целостность файла. Рассмотрим работу со штатной утилитой chdbfl.exe.
Найдите утилиту в папке bin вашей платформы (например, C:\Program Files\1cv8\8.3.X.XXXX\bin\chdbfl.exe). Укажите путь к файлу базы и обязательно установите флаг "Исправлять обнаруженные ошибки". Проанализируем результат: иногда один проход утилиты не исправляет все логические связи. Попробуйте запустить проверку 2-3 раза подряд, пока отчет не покажет отсутствие ошибок. Только после этого приступайте к снятию с УРИБ методами, описанными выше.
Если после снятия с УРИБ база все равно выдает ошибку в модуле сеанса, это значит, что сам программный код конфигурации в базе поврежден или некорректен. В этом случае, когда база уже стала "автономной", мы можем применить радикальный метод лечения:
Конфигурация -> Сохранить конфигурацию в файл..., получится файл .cf).Конфигурация -> Загрузить конфигурацию из файла....Внимание: используйте именно "Загрузить", а не "Сравнить и объединить". Загрузка полностью перезаписывает все модули и структуру, что гарантированно устраняет ошибки в программном коде Модуля сеанса или Модуля управляемого приложения.
Проанализировав все вышеперечисленные методы, мы видим, что даже в самых сложных случаях, когда база "закрыта" со всех сторон (и как узел УРИБ, и как поврежденный файл), существуют технические возможности для восстановления доступа. Главное — соблюдать последовательность: сначала физическое восстановление файла, затем снятие признака подчиненного узла, и в конце — исправление самой конфигурации.