При работе с устаревшими, но все еще актуальными системами на базе 1С:Предприятие 7.7, программисты часто прибегают к использованию внешних компонент, таких как 1С++ и FormEx. Одним из самых мощных инструментов в этой связке является класс ПоставщикДанных, который позволяет выводить списки документов и справочников в современное «Табличное поле» (Grid) с возможностью быстрой фильтрации и сортировки. Однако пользователи файловых баз (DBF) часто сталкиваются с проблемой: при перемещении по списку или обновлении данных система «замирает» на 10–20 секунд, а диспетчер задач фиксирует полную загрузку одного ядра процессора.
В этой статье мы подробно разберем, почему это происходит, проанализируем типичные ошибки в коде и выясним, как правильно настроить работу с SQLite-кэшем для достижения максимального быстродействия.
Прежде чем переходить к коду, давайте разберем теорию. В режиме SQL компонент ПоставщикДанных отправляет запросы напрямую к серверу БД. В режиме же DBF ситуация сложнее: чтобы обеспечить высокую скорость сортировки и поиска, компонент использует встроенный движок SQLite. Он создает временную базу данных, куда «пробрасывает» данные из файлов 1С (1SJOURN, DH* и др.).
Зависание, на которое жалуются разработчики, обычно происходит в момент синхронизации между виртуальным списком в SQLite и визуальным элементом ТабличноеПоле. Когда мы принудительно устанавливаем текущую строку, система должна найти соответствие между идентификатором объекта 1С и внутренним индексом строки в SQLite. Если в этот момент кэш перестраивается или индекс не оптимален, возникает Full Scan (полный перебор записей), что и вызывает скачок нагрузки на ЦП до 100%.
Рассмотрим фрагмент кода, который чаще всего становится причиной проблем. Проанализируем процедуру Обновить(), которую автор темы вызывал при каждом действии пользователя:
Процедура Обновить() Экспорт
ТекущаяКолонка = ТабличноеПоле.ТекущаяКолонка;
ТекущаяСтрока = ТабличноеПоле.ТекущаяСтрока;
СформироватьТекстЗапросаСписка();
ЗаполнитьПодвал();
УстановитьПоставщикаДанных(); // КРИТИЧЕСКАЯ ОШИБКА ЗДЕСЬ
АктивизацияКнопокОтбора();
// ... логика обновления строк ...
Если ПустоеЗначение(ТекущаяСтрока) = 0 Тогда
ТабличноеПоле.ТекущаяСтрока = ТекущаяСтрока; // ЗАВИСАНИЕ ПРОИСХОДИТ ТУТ
КонецЕсли;
ТабличноеПоле.ТекущаяКолонка = ТекущаяКолонка;
ТабличноеПоле.Активизировать();
КонецПроцедуры
В чем заключается проблема? Функция УстановитьПоставщикаДанных(), вызываемая внутри цикла обновления, скорее всего, заново создает объект ПоставщикДанных или полностью переинициализирует его параметры (ТипЗначений, Контейнер и т.д.). Для системы это означает полную потерю предыдущего состояния.
Что происходит «под капотом»:
ТабличноеПоле.ТекущаяСтрока = ТекущаяСтрока, компонент пытается найти «старый» документ в «абсолютно новом» списке. Поскольку список еще не до конца проиндексирован или находится в процессе отрисовки, поиск превращается в ресурсоемкую операцию.Вместо полной переинициализации поставщика данных, нам следует использовать методы точечного обновления. Поставщик данных умеет сам отслеживать изменения, если ему не мешать. Разберем, как оптимизировать процедуру:
Шаг 1: Устанавливайте поставщика только один раз при открытии формы (в ПриОткрытии или при первой загрузке данных).
Шаг 2: Для обновления данных используйте метод ОбновитьСтроки() самого табличного поля или метод обновления данных поставщика.
Шаг 3: Отключите АвтоОбновление, если вы планируете управлять списком вручную, но делайте это грамотно.
Правильный подход выглядит так:
// В модуле формы
Процедура ПриОткрытии()
// Инициализируем поставщик ОДИН РАЗ
ПоставщикДанных = СоздатьОбъект("ПоставщикДанных");
ПоставщикДанных.КонтейнерТабличногоПоля = "ДокументСписок";
// ... остальные настройки ...
КонецПроцедуры
Процедура ОбновитьСписок()
// Вместо пересоздания объекта просто обновляем данные
ТабличноеПоле.ОбновитьСтроки();
// Если нужно обновить именно данные в источнике (SQLite):
ПоставщикДанных.Данные.Обновить();
КонецПроцедуры
Если ваша база 1С 7.7 находится на сетевом ресурсе, а клиенты работают на Windows 7, Windows 10 или Windows Server 2008/2012, причиной тормозов может быть протокол SMB 2.0/3.0. Этот протокол агрессивно кэширует обращения к файлам (механизм Opportunistic Locking), что конфликтует со старым движком DBF.
Выясним причину задержек: если при обращении к ТекущаяСтрока происходит чтение из DBF для проверки актуальности объекта, сетевые блокировки могут затягивать этот процесс на секунды. Для решения этой проблемы системные администраторы часто рекомендуют:
DirectoryCacheLifetime, FileNotFoundCacheLifetime и FileInfoCacheLifetime в значение 0. Это заставит Windows не кэшировать список файлов в папке базы данных.Работа ПоставщикаДанных в режиме DBF неразрывно связана с созданием временных файлов. SQLite создает файлы в папке %TEMP% (обычно это файлы с расширениями .db, .tmp или без расширения). Если антивирус настроен на сканирование «на лету», он будет проверять каждый сектор, записываемый SQLite.
Проанализируем ситуацию: каждое движение по списку может инициировать чтение/запись в кэш. Антивирус блокирует файл на время сканирования, 1С ждет. Результат — загрузка ЦП и зависание интерфейса. Решение: добавьте папку временных файлов пользователя и расширения временных файлов SQLite в исключения антивируса.
Хотя в примере автора стоимость запроса в отладке низкая (18 и 9), это лишь теоретическая оценка подбора индекса в 1С. Реальная картина может отличаться. Проверьте следующее:
СформироватьТекстЗапросаСписка) нет тяжелых функций или обращений к внешним DLL в теле цикла.ТабличноеПоле.Активизировать() в конце процедуры обновления может снова вызвать событие ПриАктивизацииСтроки, которое (если в нем прописана логика обновления) создаст бесконечную петлю или цепочку вызовов, «вешающую» процессор.Главный секрет высокой производительности ПоставщикаДанных в 1С 7.7 — это стабильность объекта. Никогда не пересоздавайте поставщика данных без крайней необходимости. Помните, что каждое изменение структуры запроса или типа значений заставляет систему полностью перестраивать локальный SQLite-индекс. Соблюдая правила кэширования и оптимизируя сетевой доступ к DBF-файлам, вы сможете добиться мгновенного отклика интерфейса даже в огромных базах данных.