Почему при переводе базы 1С в режим Read-Only на уровне СУБД не открываются отчеты и как это исправить?

← На главную

При организации аналитических контуров, баз для аудиторов или реплик для снятия нагрузки с рабочей базы данных часто возникает идея перевести копию базы на уровне СУБД (например, Microsoft SQL Server или PostgreSQL) в физический режим только для чтения (READ_ONLY или STANDBY). Однако при попытке открыть форму любого отчета в управляемом приложении система завершает работу с аварийной ошибкой.

Проанализируем технические причины такого поведения платформы «1С:Предприятие» и рассмотрим правильные варианты реализации неизменяемой базы данных для формирования отчетов.

Симптомы проблемы и текст ошибки

После включения режима READ_ONLY для базы данных в SQL Server Management Studio клиентский сеанс «1С:Предприятия» успешно запускается, позволяет открывать списки справочников, документов и некоторые обработки. Но при попытке открыть любой отчет (даже абсолютно пустой, без макета СКД и строк кода) возникает невосстановимая ошибка:

Ошибка при выполнении запроса POST к ресурсу /e1cib/logForm: Ошибка СУБД: Failed to update database because the database is read-only. HRESULT=80004005, SQLSrvr: native=3906

Выясним причину: почему платформа пытается изменить данные

Разберем внутреннюю архитектуру работы управляемых форм:

Системный протокол /e1cib/logForm: При интерактивном открытии управляемой формы клиентское приложение отправляет на сервер служебный запрос. Ядро платформы 1С пытается сохранить метаданные состояния формы (размеры окон, пользовательские настройки элементов интерфейса, историю работы пользователя) в системную таблицу SystemSettings.
Низкоуровневая операция в обход кода конфигурации: Данная запись выполняется ядром платформы на уровне СУБД. Ее невозможно перехватить конструкциями Попытка ... Исключение в модулях формы или модуля менеджера отчета.
Переопределение хранилищ настроек не решает проблему: Даже если в свойствах конфигурации назначить собственные хранилища (такие как ХранилищеПользовательскихНастроекОтчетов, ХранилищеОбщихНастроек и др.), платформенная фиксация состояния интерфейса все равно обращается напрямую к системным таблицам.
Архитектурное ограничение: Платформа «1С:Предприятие» не рассчитана на прямое подключение клиентских сеансов к физически заблокированной на запись базе СУБД. Кластеру 1С всегда требуется доступ на запись в служебные таблицы сеансов, настроек и журнала.

Вариант 1. Использование штатного механизма «Копии базы данных»

Если цель перевода базы в режим чтения — распределение нагрузки и выполнение тяжелых отчетов на отдельном сервере, рассмотрим штатный функционал платформы 1С:

Основная рабочая база функционирует в стандартном режиме (Read-Write). В нее записываются все транзакции, служебные параметры и настройки сеансов.
На уровне СУБД настраивается репликация (например, группы доступности AlwaysOn в MS SQL Server с доступной для чтения вторичной репликой).
В конфигураторе или режиме «1С:Предприятие» настраивается стандартный механизм Копии баз данных. Запросы системы компоновки данных (СКД) и тяжелые отчеты автоматически или программно перенаправляются на чтение со вторичной реплики, тогда как системные настройки продолжают беспрепятственно записываться в основную базу.

Вариант 2. Организация отдельной базы для аудита и аналитиков средствами 1С

Когда требуется предоставить аудиторам или аналитикам копию рабочей базы с гарантией неизменяемости учетных данных, используем штатные средства платформы вместо блокировки СУБД:

Назначение ролей «Только чтение»: Создадим профили групп доступа и роли, в которых для всех прикладных объектов (справочников, документов, регистров) сняты права ИнтерактивноеДобавление, Редактирование, Удаление, Запись. При этом пользователям оставляем стандартные системные права на запуск приложения и СохранениеДанныхПользователя.
Установка даты запрета изменения данных: В разделе администрирования установим единую дату запрета изменения данных далеко в будущее (например, 01.01.2050). Это заблокирует проведение и изменение любых документов и регистров на уровне бизнес-логики конфигурации.
Использование периодически обновляемой копии: Разворачиваем копию рабочей базы в обычном режиме Read-Write на уровне SQL. Пользователи работают в ней с полным сохранением настроек отчетов и форм, а защита от искажения реальных данных обеспечивается регулярной перезаписью базы свежим дампом/бэкапом из рабочей среды.

Вариант 3. Программное формирование отчетов без открытия интерактивных форм

Если необходимо выполнять выгрузку данных из физической копии базы без изменения ее состояния, сформируем результат отчета программно в фоновом задании или внешнем скрипте без открытия управляемой формы.

Рассмотрим пример кода на стороне сервера, выполняющего компоновку отчета напрямую в табличный документ:


// Получаем схему компоновки данных встроенного отчета
СхемаКомпоновки = Отчеты.ВаловойДоход.ПолучитьСхемуКомпоновкиДанных();

// Инициализируем настройки по умолчанию
Настройки = СхемаКомпоновки.НастройкиПоУмолчанию;

// Создаем компоновщик макета
КомпоновщикМакета = Новый КомпоновщикМакетаКомпоновкиДанных;
МакетКомпоновки = КомпоновщикМакета.Выполнить(СхемаКомпоновки, Настройки, , , Тип("ГенераторМакетаКомпоновкиДанныхДляКоллекцииЗначений"));

// Выполняем инициализацию процессора компоновки
ПроцессорКомпоновки = Новый ПроцессорКомпоновкиДанных;
ПроцессорКомпоновки.Инициализировать(МакетКомпоновки);

// Выводим результат в табличный документ или коллекцию
ТабличныйДокумент = Новый ТабличныйДокумент;
ПроцессорВывода = Новый ПроцессорВыводаРезультатаКомпоновкиДанныхВТабличныйДокумент;
ПроцессорВывода.УстановитьДокумент(ТабличныйДокумент);
ПроцессорВывода.Вывести(ПроцессорКомпоновки);

Такой способ не инициирует веб-вызов /e1cib/logForm, не обращается к таблице SystemSettings и позволяет извлекать данные отчетов даже в условиях жестких ограничений пользовательских прав.