В процессе разработки или обновления конфигураций 1С программисты нередко сталкиваются с ситуацией, когда внесенные изменения оказываются ошибочными или нежелательными. Особенно критичной ситуация становится при неудачном подключении к хранилищу конфигурации, когда локальная копия обновляется данными из устаревшего или некорректного источника. В таких случаях в заголовке конфигуратора появляется символ «!» (восклицательный знак), сигнализирующий о том, что основная конфигурация отличается от конфигурации базы данных.
Рассмотрим детально, как можно вернуть систему в стабильное состояние, разберем механизмы хранения метаданных в MS SQL Server и проанализируем риски использования нештатных методов.
Для начала выясним причину возникновения состояния «измененности». В системе 1С:Предприятие 8 сосуществуют две конфигурации:
Когда мы вносим изменения, они записываются только в основную конфигурацию. Пока не нажата клавиша F7 (Обновить конфигурацию базы данных) или не выполнено принятие изменений, пользователи работают на старом коде. Символ «!» означает, что основная конфигурация «ушла вперед» или просто изменилась относительно конфигурации БД.
Проанализируем самый простой и безопасный способ отката — штатную функцию платформы. Если вы еще не успели применить изменения к базе данных (не обновляли конфигурацию БД), вы можете просто «выбросить» все текущие правки в конфигураторе и загрузить в него ту конфигурацию, с которой в данный момент работают пользователи.
Разберем этот процесс по шагам:
Что происходит в этот момент? Система берет данные из таблиц, отвечающих за рабочую конфигурацию, и перезаписывает ими текущую редактируемую конфигурацию. Все ваши незафиксированные изменения (коды модулей, новые реквизиты, формы) будут удалены безвозвратно. Это самый «гуманный» и правильный способ с точки зрения лицензионной чистоты и целостности данных.
Бывают ситуации, когда штатный метод недоступен. Например, когда конфигуратор вообще не открывается или при попытке входа возникает критическая ошибка (дамп). В таких случаях специалисты прибегают к прямым запросам к базе данных на уровне MS SQL Server.
Рассмотрим подробнее механизм хранения метаданных в SQL. За конфигурацию отвечают следующие основные таблицы:
Config: хранит текущую основную конфигурацию.DBSchema: хранит структуру таблиц (описание полей, типов данных).ConfigSave: содержит промежуточные, временно сохраненные данные.Params: хранит служебную информацию, настройки и признаки состояния (например, признак того, что конфигурация изменена).Если нам нужно «убить» последнюю необновленную конфигурацию, которая мешает нормальной работе, мы можем манипулировать этими таблицами. Важно: любые действия с SQL-таблицами должны производиться только после создания полной резервной копии базы данных (бэкапа).
Один из вариантов очистки состояния «измененности» заключается в удалении записей из таблицы Config и их восстановлении из надежного источника (например, из рабочей конфигурации). Однако чаще всего для сброса блокировок или некорректных флагов обновления используется очистка определенных строк в таблице Params. Это позволяет системе «забыть» о том, что была начата какая-то процедура обновления, которая зависла или привела к ошибке.
Пример логики запроса для удаления признака «динамического обновления», который часто мешает нормальному входу:
-- Пример запроса для удаления информации о динамическом обновлении (использовать с осторожностью!)
DELETE FROM Params WHERE FileName = 'DBChanges'
DELETE FROM Params WHERE FileName = 'DynamicallyUpdated'
Выясним причины, по которым не стоит злоупотреблять SQL-методами:
Config, но в таблице DBSchema останутся ссылки на объекты, которых больше нет в основной конфигурации, база может прийти в полную негодность.Если вы обнаружили, что конфигурация находится в странном состоянии, или вы случайно получили данные из древнего хранилища, выполните следующие действия в строгом порядке:
Шаг 1: Создание бэкапа. Это золотое правило любого администратора и программиста. Прежде чем пробовать штатные или нештатные методы, сделайте выгрузку информационной базы (.dt) или, что еще лучше, сделайте Full Backup средствами SQL Server. Если что-то пойдет не так, у вас будет точка возврата. При обслуживании большого количества баз процесс можно автоматизировать с помощью программы для пакетного архивирования и тестирования 1С.
Шаг 2: Отключение от хранилища. Если проблема связана с хранилищем конфигурации, сначала разорвите связь с ним (меню Конфигурация -> Хранилище конфигурации -> Отключиться от хранилища). Это предотвратит попытки системы синхронизировать ошибочные данные.
Шаг 3: Попытка штатного отката. Используйте Возврат к конфигурации БД. В 99% случаев этого достаточно, чтобы убрать восклицательный знак и вернуть код в рабочее состояние.
Шаг 4: Очистка кэша. Иногда «глюки» конфигуратора — это вовсе не проблема в базе данных, а мусор в локальных временных файлах. Попробуйте удалить базу из списка и добавить её заново или вручную очистить содержимое папок %AppData%\Local\1C\1Cv8 и %AppData%\Roaming\1C\1Cv8. Для автоматизации этой процедуры можно использовать скрипт для быстрой очистки кэша 1С.
Шаг 5: Экстренные меры. Только если конфигуратор не открывается и база данных заблокирована, рассмотрите возможность применения SQL-запросов к таблицам Config и Params, опираясь на проверенные инструкции из сообщества (например, статьи на Infostart).
Подводя итог, можно сказать: знание структуры SQL-таблиц 1С — полезный навык для критических ситуаций, но в повседневной практике штатные инструменты платформы справляются с задачами отката гораздо безопаснее и эффективнее.