В процессе администрирования клиент-серверных баз данных «1С:Предприятие 8.3» технические специалисты нередко сталкиваются с загадочными и критическими сбоями слоя работы с базами данных (SDBL). Одним из наиболее неприятных проявлений таких неполадок является ошибка: «Ошибка SDBL: В таблице UsersWorkHistory нет поля с именем ECSActivity». Данная проблема полностью блокирует работу пользователей, не позволяя проводить или записывать любые документы, а также делает невозможным создание начального образа подчиненного узла в распределенных информационных базах (РИБ).
В рамках этой статьи мы подробно разберем природу возникновения данной ошибки, проанализируем взаимосвязь внутренних механизмов платформы 1С и СУБД, а также предложим несколько надежных и проверенных способов решения проблемы — от простых организационных обходов до глубокой технической реструктуризации базы данных.
Для того чтобы эффективно бороться с технической проблемой, необходимо понимать, какие внутренние механизмы платформы задействованы в сбое. Проанализируем структуру базы данных на физическом уровне.
Таблица UsersWorkHistory (на уровне СУБД она обычно носит имя _UsersWorkHistory) представляет собой системный служебный регистр платформы «1С:Предприятие». В ней хранится история работы пользователей — список из последних двухсот объектов (документов, справочников, отчетов), которые открывал, изменял или создавал каждый конкретный пользователь базы данных. Эта таблица используется исключительно для вывода панели «История» в интерфейсе «Такси» и никак не влияет на проведение документов, расчеты или бизнес-логику прикладного решения.
Поле ECSActivity (в таблице СУБД — _ECSActivity) появилось в структуре системных таблиц относительно недавно. Аббревиатура ECS расшифровывается как Enterprise Collaboration System — это встроенная в платформу Система взаимодействия (мессенджер, система обмена сообщениями и видеозвонками между пользователями 1С). Поле ECSActivity отвечает за синхронизацию статусов активности пользователей и фиксацию событий Системы взаимодействия в истории их работы.
Ошибка SDBL возникает в тот момент, когда платформа 1С пытается обновить историю работы пользователя при записи любого бизнес-объекта, но обнаруживает жесткое расхождение (рассинхронизацию) между ожидаемой логической структурой метаданных платформы и реальной физической структурой таблиц на SQL-сервере.
Основными причинами такого расхождения являются:
Рассмотрим по шагам методы решения этой проблемы, начиная с самых простых и заканчивая радикальными системными изменениями.
Если пользователи внезапно потеряли возможность проводить документы, а в журнале регистрации фиксируется невосстановимая ошибка обращения к ресурсу /e1cib/logForm, наиболее быстрым временным решением является сброс кэша и перезапуск службы сервера приложений.
Выполним процедуру перезапуска по шагам:
services.msc).1C:Enterprise 8.3 Server Agent).После перезапуска службы сервера внутренний кэш метаданных SDBL полностью очистится, и платформа на некоторое время восстановит стабильную работу с таблицей истории. Однако помните, что при повторном возникновении определенных триггеров (например, при попытке создать узел РИБ) ошибка может вернуться. Поэтому перейдем к более долгосрочным методам исправления.
Как показывает практика практикующих специалистов, системный баг с полем ECSActivity проявляется исключительно в клиент-серверном (SQL) режиме работы. В файловом режиме механизм СУБД SDBL работает по другим алгоритмам и не вызывает подобных сбоев.
Если вам критически важно создать начальный образ распределенной информационной базы (РИБ) со сложными фильтрами, а SQL-сервер выдает ошибку, выполните следующие действия:
.dt через Конфигуратор..dt в эту новую файловую базу.Поскольку таблица _UsersWorkHistory не содержит бизнес-данных, мы можем абсолютно безболезненно для учета полностью очистить ее содержимое. Это заставит платформу принудительно переинициализировать структуру таблицы при первом же входе любого пользователя.
Для безопасной очистки таблицы воспользуемся штатным программным методом платформы 1С. Создайте внешнюю обработку или запустите следующий код в консоли кода:
Процедура ОчиститьСистемнуюТаблицуИстории() Экспорт
Попытка
УстановитьПривилегированныйРежим(Истина);
ИсторияРаботыПользователя.ОчиститьВсе();
Сообщить("Таблица UsersWorkHistory успешно очищена средствами платформы!");
Исключение
Сообщить("Не удалось очистить историю работы: " + ОписаниеОшибки());
КонецПопытки;
КонецПроцедуры
Выполнение метода ИсторияРаботыПользователя.ОчиститьВсе() корректно сбросит все индексы SDBL, удалит записи из базы данных и перестроит внутреннее представление таблицы _UsersWorkHistory на уровне СУБД.
Обычное «Тестирование и исправление» (ТиИ) со стандартными настройками часто не помогает решить проблему, если не задействован механизм изменения физической структуры таблиц на диске. Нам необходимо принудительно заставить платформу сверить структуру метаданных с СУБД и досоздать недостающее поле _ECSActivity.
Проанализируем процедуру реструктуризации по шагам:
Во время реструктуризации платформа 1С создаст временные копии всех таблиц в СУБД, перенесет туда данные и воссоздаст структуру в строгом соответствии с требованиями текущей версии платформы, гарантированно добавив поле ECSActivity во все необходимые таблицы.
Поскольку поле ECSActivity напрямую связано с Системой взаимодействия (компонентом ECS), сбой может быть вызван некорректной регистрацией информационной базы на сервере взаимодействия. Попробуем временно отключить этот механизм.
Для высоконагруженных систем, где остановка базы на реструктуризацию невозможна по регламенту, системные администраторы могут прибегнуть к прямому добавлению поля на уровне MS SQL Server или PostgreSQL. При создании начального образа РИБ платформа налету создает новые таблицы базы-приемника. Мы можем перехватить этот процесс с помощью DDL-триггера СУБД и автоматически добавлять недостающее поле _ECSActivity.
Рассмотрим пример создания такого DDL-триггера для СУБД MS SQL Server, который автоматически внедряет колонку при генерации таблицы _UsersWorkHistory:
CREATE TRIGGER [TRG_Add_ECSActivity]
ON DATABASE
FOR CREATE_TABLE
AS
BEGIN
SET NOCOUNT ON;
DECLARE @EventData XML = EVENTDATA();
DECLARE @TableName NVARCHAR(255) = @EventData.value('(/EVENT_INSTANCE/ObjectName)[1]', 'NVARCHAR(255)');
IF @TableName LIKE '%_UsersWorkHistory%'
BEGIN
DECLARE @SQL NVARCHAR(MAX);
SET @SQL = 'ALTER TABLE ' + QUOTENAME(@TableName) + ' ADD [_ECSActivity] [binary](1) NULL;';
EXEC sp_executesql @SQL;
END
END;
Этот триггер автоматически отследит момент создания новой таблицы истории работы (в том числе при выгрузке РИБ) и добавит туда колонку _ECSActivity с типом binary(1), что позволит процессу создания образа успешно завершиться без падения SDBL-транзакции.
Описанная ошибка с полем ECSActivity является официально признанной ошибкой системного ядра 1С:Предприятие определенных версий. Разработчики исправили этот баг SDBL в последующих обновлениях.
Если вы хотите раз и навсегда избавиться от этой проблемы без использования костылей, файловых баз и SQL-триггеров, настоятельно рекомендуем запланировать обновление технологической платформы «1С:Предприятие» до стабильных версий веток 8.3.18, 8.3.20, 8.3.22 или выше. В современных релизах платформы механизмы синхронизации структуры СУБД существенно оптимизированы, а ошибки создания начальных образов РИБ полностью устранены.