При интеграции 1С с внешними базами данных, такими как SQLite, особенно в условиях высокой интенсивности обновления (1–3 раза в секунду), перед разработчиком встает выбор оптимального механизма доступа. Нам необходимо обеспечить минимальные задержки при чтении, исключить взаимные блокировки с пишущим процессом и минимизировать нагрузку на систему. В данной статье мы разберем основные методы получения данных, их преимущества и технические нюансы реализации.
Рассмотрим сценарий: имеется небольшая оперативная таблица в SQLite (20 строк, 12 параметров). Внешняя программа (на языке C) записывает в нее данные от датчиков несколько раз в секунду. 1С должна выступать в роли потребителя этих данных. Основная проблема здесь заключается не в объеме передаваемой информации, а в частоте обращений и потенциальных конфликтах доступа к файлу БД.
Метод через ADO (ActiveX Data Objects) является одним из самых гибких и популярных. Мы используем COM-объект ADODB.Connection и SQLite ODBC Driver. Этот способ позволяет нам полностью контролировать жизненный цикл соединения и выполнять произвольные SQL-запросы.
Разберем по шагам реализацию этого метода:
PRAGMA.Рассмотрим пример кода для получения данных через ADO:
// Создаем объекты для подключения
Connection = Новый COMОбъект("ADODB.Connection");
Recordset = Новый COMОбъект("ADODB.Recordset");
// Формируем строку подключения с указанием таймаута
ConnectionString = "Driver={SQLite3 ODBC Driver};Database=C:\Data\sensors.db;StepAPI=0;SyncPragma=NORMAL;BusyTimeout=5000;";
Попытка
Connection.Open(ConnectionString);
// Выполняем запрос к нашей оперативной таблице
ТекстЗапроса = "SELECT * FROM SensorTable LIMIT 20";
Recordset.Open(ТекстЗапроса, Connection);
Пока Recordset.EOF = 0 Цикл
// Обработка данных
Параметр1 = Recordset.Fields("Param1").Value;
// ... логика обработки ...
Recordset.MoveNext();
КонецЦикла;
Recordset.Close();
Connection.Close();
Исключение
Сообщить("Ошибка доступа к SQLite: " + ОписаниеОшибки());
КонецПопытки;
Платформа 1С позволяет подключить SQLite как Внешний источник данных. Это "родной" механизм платформы, который интегрирует внешние таблицы в пространство объектов метаданных. Мы можем работать с таблицей SQLite почти так же, как со справочником или регистром сведений 1С.
Проанализируем особенности этого подхода:
Важный нюанс: При настройке подключения через ODBC для SQLite в мастере настройки ВИД иногда рекомендуется выбирать тип СУБД MySQL, если стандартный драйвер ведет себя некорректно. Это позволяет обойти некоторые ограничения парсера метаданных 1С.
Для достижения максимальной производительности можно использовать Внешнюю компоненту (Native API). В этом случае мы обходим уровни абстракции ODBC и ADO, работая напрямую с sqlite3.dll через C++ или Rust.
Выясним преимущества работы через ВК:
Независимо от выбранного способа, мы столкнемся с проблемой блокировок. SQLite по умолчанию использует Rollback Journal, при котором записывающий процесс полностью блокирует базу для читателей. При частоте 3 обновления в секунду 1С будет постоянно получать ошибку Database is locked.
Разберем решение — включение режима WAL (Write-Ahead Logging). В этом режиме читатели и писатели не блокируют друг друга. Рассмотрим, как это настроить:
PRAGMA journal_mode=WAL;.PRAGMA synchronous = NORMAL; для ускорения записи без потери целостности.Проанализируем ситуацию, когда запись все же кратковременно блокирует файл (например, при фиксации контрольной точки WAL). Чтобы 1С не "вылетала" с ошибкой, необходимо настроить Busy Timeout. Это время, которое драйвер будет ждать освобождения базы перед тем, как вернуть ошибку приложению.
В строке подключения ADO это выглядит так: ...;StepAPI=0;BusyTimeout=5000;. Это означает, что 1С будет ждать до 5 секунд, делая микро-повторы запроса в фоновом режиме. Для пользователя это будет выглядеть как кратковременное замирание на миллисекунды, а не крах программы.
Выясним, какой метод выгоднее в конкретных условиях:
WAL и BusyTimeout этот метод обеспечит стабильную работу при 1–3 запросах в секунду.Подводя итог, для таблицы в 20 строк оптимальным решением будет ADO с обязательным переводом базы данных SQLite в режим WAL. Это обеспечит баланс между скоростью разработки и производительностью системы.