В процессе разработки в среде 1С:Предприятие 8 мы часто сталкиваемся с ситуациями, когда информационная база начинает вести себя некорректно из-за остаточных данных в системных таблицах. Одной из наиболее неприятных проблем является так называемое «фантомное» подключение к хранилищу конфигурации. Особенно часто это проявляется в базах, являющихся узлами распределенной информационной базы (РИБ). База настойчиво требует авторизации в хранилище, которого не существует, или показывает объекты захваченными, хотя связь с хранилищем давно разорвана.
В данной статье мы разберем, как «отучить» конфигурацию от попыток подключения к несуществующему хранилищу, проанализируем структуру системных таблиц и рассмотрим пошаговый алгоритм очистки базы данных.
Прежде чем переходить к радикальным мерам на уровне SQL, нам необходимо убедиться, что штатные средства платформы действительно не справляются. Типичные симптомы проблемы выглядят так:
Рассмотрим последовательно методы решения этой задачи — от простых к более сложным.
Попробуем сначала применить штатный механизм платформы для принудительного отключения. Для этого мы будем использовать запуск 1С, задействовав командную строку Windows с определенными параметрами. Проанализируем действие ключа /ConfigurationRepositoryUnbindCfg.
Алгоритм действий следующий:
"C:\Program Files\1cv8\common\1cestart.exe" CONFIG /F "ПутьКВашейБазе" /N "Админ" /P "Пароль" /ConfigurationRepositoryUnbindCfg -force
Параметр -force здесь критически важен, так как он заставляет систему игнорировать некоторые проверки целостности. Однако, как показывает практика, в сложных случаях (особенно в РИБ) этот метод может не дать результата, так как флаги подключения «застревают» глубоко в структурах SQL-таблиц.
Если штатные ключи запуска не помогли, перейдем к работе с базой данных на уровне СУБД. Выясним причину: 1С хранит информацию о связи с хранилищем в виде специальных бинарных данных (файлов внутри базы). В версиях платформы до 8.3.9 и в некоторых случаях в более поздних, эти данные располагаются в таблице Files.
Важно: Перед выполнением любых операций на уровне SQL обязательно создайте полную резервную копию базы данных!
Проанализируем записи в таблице Files. Нас интересуют записи, в именах которых встречается вхождение depot. Именно они отвечают за параметры подключения к репозиторию. Выполним следующий запрос:
DELETE FROM [Ваша_База].[dbo].[Files]
WHERE [FileName] LIKE '%depot%'
После удаления этих записей 1С перестанет видеть настройки хранилища при запуске. Во многих случаях это позволяет вернуть возможность редактирования конфигурации и корректно «принять» изменения по каналам РИБ, для чего в штатном режиме часто используется автоматическое обновление конфигурации.
В современных версиях платформы (начиная с 8.3.9) разработчики выделили работу с хранилищем в отдельную системную таблицу — DepotFiles. Если ваша база работает на актуальной платформе, информация о «фантомном» подключении может находиться именно там.
Разберем процесс очистки этой таблицы. Если база не должна быть подключена к хранилищу, таблица DepotFiles должна быть полностью пустой. Мы можем использовать команду TRUNCATE для быстрой очистки:
-- Очистка таблицы метаданных хранилища
TRUNCATE TABLE DepotFiles;
После выполнения этого запроса рекомендуется также проверить таблицу ConfigSave. Если в ней остались «грязные» записи от неудавшегося подключения, их также стоит очистить, чтобы Конфигуратор открылся в чистом состоянии.
Иногда даже после очистки файлов depot база продолжает хранить кэшированное состояние подключения. Эти данные могут находиться в таблице Params в записи с именем v8system.cfg.
Проанализируем ситуацию: удаление этого файла сбросит общие настройки информационной базы. 1С автоматически пересоздаст этот файл при следующем запуске с параметрами по умолчанию. Это помогает в случаях, когда база «намертво» запомнила свой статус как части хранилища.
DELETE FROM Params WHERE FileName = 'v8system.cfg';
После того как мы провели манипуляции на уровне SQL, крайне важно исключить влияние кэширования на стороне сервера приложений и клиентского компьютера. Без этого шага вы можете продолжать видеть старое состояние базы.
Выполним следующие шаги:
1C:Enterprise 8.3 Server Agent (ragent). В этом процессе может быть полезна автоматическая очистка серверного кэша с помощью скриптов. Перейдите в папку с данными кластера (обычно это C:\Program Files\1cv8\srvinfo) и удалите содержимое папок snccntx. После этого запустите службу заново.%AppData%\1C\1cv8.Рассмотрим специфику распределенных систем. Если проблемная база является подчиненным узлом РИБ, некоторые специалисты рекомендуют сначала временно отвязать базу от РИБ, выполнив команду ПланыОбмена.УстановитьГлавныйУзел(Неопределено), произвести очистку хранилища, а затем вернуть статус подчиненного узла. Однако, как показывает практика, методы с очисткой таблицы Files через SQL (вариант 2) обычно позволяют решить проблему без вмешательства в структуру РИБ.
Проанализировав все способы, можно сделать вывод: наиболее эффективным методом борьбы с фантомными подключениями является сочетание очистки таблицы Files (или DepotFiles) и полного сброса кэша сервера приложений. Это гарантированно удаляет все «следы» хранилища, которые мешают нормальной работе Конфигуратора.