Потеря данных в ХранилищеСистемныхНастроек — ситуация неприятная, но поправимая. В этой области 1С хранит пользовательские настройки форм, отчеты, настройки динамических списков и другие элементы персонализации интерфейса. Если эти данные были случайно удалены или повреждены, их можно восстановить из резервной копии базы данных. Рассмотрим подробно, как это сделать программно и на уровне базы данных.
Прежде чем приступать к восстановлению, разберем, как устроено хранилище. В платформе 1С 8.3 системные настройки хранятся в специализированной таблице. Если мы работаем с SQL-версией, это таблица _SystemSettings. Каждая запись в ней жестко привязана к трем параметрам:
Сами данные настройки упакованы в ХранилищеЗначения. Это означает, что просто «прочитать» их как текст в SQL не получится — их нужно извлечь средствами встроенного языка 1С или правильно перенести двоичные данные.
Проанализируем самый безопасный метод — написание внешней обработки, которая выгрузит данные из бэкапа в файл, а затем загрузит их в рабочую базу. Этот способ хорош тем, что он не требует прямого вмешательства в структуру таблиц SQL и учитывает объектную логику 1С.
Шаг 1. Выгрузка данных из резервной копии
Развернем бэкап как отдельную базу и запустим в ней обработку. Нам понадобится метод ХранилищеСистемныхНастроек.Выбрать(). Посмотрим на пример кода, который перебирает настройки:
Выборка = ХранилищеСистемныхНастроек.Выбрать();
ТаблицаДанных = Новый ТаблицаЗначений;
ТаблицаДанных.Колонки.Добавить("Пользователь");
ТаблицаДанных.Колонки.Добавить("КлючОбъекта");
ТаблицаДанных.Колонки.Добавить("КлючНастройки");
ТаблицаДанных.Колонки.Добавить("ЗначениеСтрокой");
Пока Выборка.Следующий() Цикл
НоваяСтрока = ТаблицаДанных.Добавить();
НоваяСтрока.Пользователь = Выборка.Пользователь;
НоваяСтрока.КлючОбъекта = Выборка.КлючОбъекта;
НоваяСтрока.КлючНастройки = Выборка.КлючНастройки;
// Получаем само значение настройки
ЗначениеНастройки = ХранилищеСистемныхНастроек.Получить(Выборка.КлючОбъекта, Выборка.КлючНастройки, , Выборка.Пользователь);
// Сериализуем значение в строку для сохранения в файл
НоваяСтрока.ЗначениеСтрокой = ЗначениеВСтрокуВнутр(ЗначениеНастройки);
КонецЦикла;
ТаблицаДанных.Записать("C:\temp\settings_backup.xml");
Шаг 2. Загрузка данных в рабочую базу
Теперь в основной базе выполним обратную операцию. Проанализируем важный нюанс: при использовании ЗначениеИзСтрокиВнутр() платформа восстанавливает объект из строкового представления. Нам остается только применить метод Сохранить().
// Читаем таблицу из файла
ТаблицаДанных = Новый ТаблицаЗначений;
// ... код чтения файла ...
Для Каждого Стр Из ТаблицаДанных Цикл
Попытка
ОбъектНастройки = ЗначениеИзСтрокиВнутр(Стр.ЗначениеСтрокой);
ХранилищеСистемныхНастроек.Сохранить(Стр.КлючОбъекта, Стр.КлючНастройки, ОбъектНастройки, , Стр.Пользователь);
Исключение
Сообщить("Ошибка восстановления для: " + Стр.КлючОбъекта);
КонецПопытки;
КонецЦикла;
Выясним причину, почему метод ЗначениеВСтрокуВнутр может иногда подводить. Если конфигурации бэкапа и рабочей базы различаются (например, было обновление), типы данных могут не совпасть. В таких случаях надежнее использовать СериализаторXDTO.
Рассмотрим подробнее этот подход. Сериализация в XML через XDTO позволяет более гибко работать со структурами данных. Мы можем сохранить настройки в XML-файл, который будет содержать описание типов. Это особенно актуально для сложных настроек компоновки данных (СКД).
Если объем данных огромен и пользователей сотни, программный перебор может занять много времени. Рассмотрим вариант прямого копирования таблицы на уровне СУБД. Выясним главное условие: идентификаторы пользователей (UUID) в обеих базах должны быть идентичны.
Если рабочая база — это та же самая база, в которой просто очистили настройки, то UUID пользователей совпадут. Если же база создавалась с нуля и пользователи заводились вручную — этот метод не сработает, так как ссылки в таблице настроек будут указывать на несуществующих в новой базе субъектов.
Пример логики SQL-запроса (условно):
INSERT INTO WorkDB.dbo._SystemSettings
SELECT * FROM BackupDB.dbo._SystemSettings
WHERE NOT EXISTS (SELECT 1 FROM WorkDB.dbo._SystemSettings WHERE ...)
Внимание: Любые операции на уровне SQL крайне опасны и должны выполняться только после создания актуального бэкапа рабочей базы!
Проанализируем ситуацию, когда после восстановления настройки всё равно «не видны» пользователю. Рассмотрим основные причины:
%AppData%\1C\1cv8 у пользователя.GUID, настройка может выдавать ошибку при открытии.Если ваша конфигурация построена на базе Библиотеки стандартных подсистем (БСП), задача упрощается. В БСП предусмотрен регистр сведений СохраненныеНастройки (или аналогичные, в зависимости от версии), а также типовая обработка «Копирование настроек пользователей». Посмотрим, как это помогает: вы можете воспользоваться типовым механизмом выгрузки/загрузки данных в формате XML (обработка ВыгрузкаЗагрузкаДанныхXML.epf), выбрав только те объекты, которые отвечают за хранение настроек. Это позволит избежать написания собственного кода.
Мы разобрали несколько методов восстановления: от гибкого программного кода с использованием ЗначениеВСтрокуВнутр до прямого копирования таблиц SQL. Самым стабильным и контролируемым является первый способ, так как он позволяет фильтровать данные и обрабатывать ошибки в процессе загрузки. Помните, что регулярное создание бэкапов — лучший способ избежать подобных трудозатрат в будущем.