Как просмотреть структуру журнала регистрации 1С в формате SQLite и перенести данные в MS SQL Server?

С переходом платформы 1С:Предприятие 8.3 на новый формат журнала регистрации (файлы с расширением .lgd), данные теперь хранятся в базе данных SQLite. Это открывает широкие возможности для анализа логов сторонними инструментами, но одновременно ставит перед разработчиками новые задачи: от понимания внутренней структуры таблиц до корректной миграции накопленных данных в корпоративные хранилища на базе MS SQL Server. В этой статье мы подробно разберем, как устроена база данных журнала регистрации, какими средствами ее анализировать и как решить специфические проблемы при импорте данных через SQL Server Integration Services (SSIS).

Анализ структуры базы данных журнала регистрации

Для начала проанализируем, как именно 1С хранит информацию. В отличие от старого текстового формата (.elf), формат SQLite является реляционным. Чтобы увидеть структуру таблиц «изнутри», мы можем воспользоваться стандартной утилитой командной строки sqlite3 или специализированным ПО. Рассмотрим схему основной таблицы EventLog, которая содержит записи о событиях:

CREATE TABLE EventLog (
    rowID INTEGER PRIMARY KEY AUTOINCREMENT,
    severity INTEGER,
    date INTEGER,
    connectID INTEGER,
    session INTEGER,
    transactionStatus INTEGER,
    transactionDate INTEGER,
    transactionID INTEGER,
    userCode INTEGER,
    computerCode INTEGER,
    appCode INTEGER,
    eventCode INTEGER,
    comment TEXT,
    metadataCodes TEXT,
    sessionDataSplitCode INTEGER,
    dataType INTEGER,
    data TEXT,
    dataPresentation TEXT,
    workServerCode INTEGER,
    primaryPortCode INTEGER,
    secondaryPortCode INTEGER
);

Обратим внимание на важный нюанс: большинство полей в главной таблице являются ссылками (идентификаторами) на другие таблицы-справочники. Это сделано для оптимизации размера файла. Рассмотрим основные связанные таблицы, которые нам понадобятся для расшифровки данных:

• UserCodes — содержит имена пользователей (name) и их уникальные идентификаторы (uuid).
• ComputerCodes — имена рабочих станций, с которых выполнялись действия.
• EventCodes — названия самих событий (например, «Данные.Изменение» или «Сеанс.Начало»).
• MetadataCodes — идентификаторы объектов метаданных (справочников, документов), к которым обращались пользователи.
• AppCodes — названия приложений (Тонкий клиент, Конфигуратор и т.д.).

Для получения читаемого отчета нам потребуется объединять эти таблицы. Например, проанализируем ситуацию, когда нужно сопоставить событие и имя пользователя. Для этого в SQL-запросе мы будем использовать LEFT JOIN между EventLog и UserCodes по полю userCode.

Проблема миграции данных в MS SQL Server через SSIS

Часто возникает задача перенести исторические данные из .lgd файла в полноценную базу MS SQL для долгосрочного хранения или построения сложных отчетов в Power BI. При использовании SQL Server Integration Services (SSIS) разработчики часто сталкиваются с ошибкой привязки столбцов типа TEXT.

Выясним причину: SQLite драйвер передает строковые поля большого объема как DT_NTEXT или специфический тип DBTYPE_IUNKNOWN. В то же время целевой столбец в MS SQL (например, nvarchar) ожидает более понятный формат. Ошибка 0xC002F446 сообщает нам о неподдерживаемом преобразовании. Чтобы решить эту проблему, разберем по шагам алгоритм настройки пакета SSIS:

1. Добавим в поток данных (Data Flow) источник ODBC Source, указывающий на файл 1Cv8.lgd.
2. Сразу после источника установим компонент «Преобразование данных» (Data Conversion).
3. Внутри компонента выберем все столбцы типа TEXT (например, comment, data, dataPresentation).
4. Для каждого такого столбца выберем тип данных «Строка в Юникоде [DT_WSTR]». Обязательно укажите достаточную длину (например, 4000 символов или больше, если это необходимо).
5. В OLE DB Destination (приемник MS SQL) связываем не оригинальные поля из источника, а именно «Производные столбцы», которые мы получили после преобразования.

Этот метод позволяет корректно «пробросить» данные через конвейер SSIS, минуя ограничения стандартных драйверов OLE DB.

Особенности интерпретации полей 1С

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

Формат даты: В полях date и transactionDate хранится целое число. Это количество 100-наносекундных интервалов, прошедших с 0001-01-01. Чтобы перевести это в привычный формат в MS SQL, нам придется использовать математические формулы. Рассмотрим пример логики: для получения Unix Timestamp нужно вычесть смещение (около 62135596800 секунд), а затем преобразовать остаток в дату.

Поле Важность (Severity): Это числовой код. Разберем основные значения, которые помогут нам при фильтрации:

• 0 — Примечание (Information).
• 1 — Информация.
• 2 — Предупреждение (Warning).
• 3 — Ошибка (Error).

Поле Данные (Data): Здесь могут находиться сериализованные строки. Если объект простой (например, ссылка), он будет представлен в виде внутреннего формата 1С ({"#", ...}). Для работы с этими данными на стороне SQL Server может потребоваться написание парсеров строк или использование регулярных выражений.

Рекомендованные инструменты для работы

Если нам нужно просто быстро просмотреть структуру или выполнить пару проверочных запросов без построения сложных систем миграции, рекомендуем следующие программы:

• DB Browser for SQLite: Самый простой и наглядный инструмент. Позволяет сразу увидеть вкладку «Структура БД», где перечислены все индексы и типы полей.
• DBeaver: Универсальный менеджер. Он крайне удобен тем, что позволяет одновременно подключиться и к SQLite-файлу лога, и к вашей базе MS SQL, позволяя копировать данные практически «руками» через интерфейс.
• SQLiteStudio: Легкая утилита, которая отлично справляется с кодировками 1С и корректно отображает кириллицу в текстовых полях comment.

Важное примечание: Прежде чем открывать файл 1Cv8.lgd сторонним софтом, обязательно создайте его копию. 1С на сервере может блокировать файл для записи, что приведет к ошибкам доступа или повреждению базы при попытке чтения активного лога.

Таким образом, мы рассмотрели устройство журнала регистрации в формате SQLite, разобрали схему его таблиц и нашли эффективный способ решения проблемы типизации данных при переносе логов в SQL Server. Использование компонента Data Conversion в SSIS является ключевым моментом для успешной автоматизации процесса импорта.