Как исправить ошибки ADO и OLE DB при работе с DBF-файлами в 1С 7.7?

← На главную

При интеграции 1С 7.7 со сторонними системами часто возникает необходимость читать или обновлять данные в таблицах формата DBF. Однако при попытке выполнения команд UPDATE или проходе по выборке SELECT с помощью провайдеров Microsoft JET OLEDB или VFPOLEDB разработчики столкнутся с критическими ошибками:

"Microsoft JET Database Engine: Ключ поиска не найден ни в одной записи" — возникает при попытке вызова MoveNext() или при выполнении UPDATE с условием WHERE.
"FAILED! ICommandText::Execute(): Variable 'ИМЯ_ПЕРЕМЕННОЙ' is not found" — возникает при попытке выполнить SQL-запрос через Visual FoxPro OLE DB Provider.

Рассмотрим подробнее причины возникновения этих ошибок и проанализируем проверенные способы их решения.

Причина возникновения ошибки при работе через ADO

Разберем механику работы провайдеров OLE DB. В заголовке каждого DBF-файла по смещению 28 (0x1C) содержится однобайтовый флаг, отвечающий за наличие структурного индекса .CDX. Если этот байт равен 0x01, OLE DB провайдер (как Microsoft JET, так и VFPOLEDB) автоматически пытается найти и подключить одноименный индексный файл.

Если таблицы создавались во внешних DOS-приложениях (например, на Clipper или FoxPro), индексные выражения часто включают функции пользователя или глобальные переменные приложения (например, CFG_SBFIO). Провайдер OLE DB в среде Windows не знает о существовании этих переменных и при попытке вычислить выражение индекса выдает ошибку о ненайденной переменной или сбивается с позиционирования по записям при перемещении курсора.

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


DBConn = CreateObject("ADODB.Connection");
DBConn.Open("Provider=Microsoft.Jet.OLEDB.4.0;" +
    "Data Source=" + СокрЛП(КаталогБазы) + ";" +
    "Extended Properties=""DBASE IV;"";"); 
DBConn.Execute("UPDATE [tabl#DBF] SET FIO='Петров Василий Пупкин' WHERE KOD=131559");

Если поле KOD или любое другое поле таблицы участвует в вычисляемом индексе .CDX, стандартный вызов ADO завершается аварийно.

Способ 1. Использование компоненты 1SQLite (Рекомендуемый)

Наиболее надежный способ работы со сторонними DBF-файлами в разделенном режиме — использование внешней компоненты 1SQLite. Она позволяет монтировать произвольные DBF-файлы в качестве виртуальных таблиц в RAM-базу данных SQLite.

При таком подходе 1SQLite считывает DBF-файл на физическом уровне как набор байтовых записей, полностью игнорируя связанные файлы .CDX и вычисляемые индексные выражения Clipper/FoxPro.

Разберем пример кода выполнения запроса через 1SQLite:


Если ЗагрузитьВнешнююКомпоненту("1sqlite.dll") = 0 Тогда
    Предупреждение("Не удалось загрузить 1sqlite.dll");
    Возврат;
КонецЕсли;

БазаДанных = СоздатьОбъект("SQLiteBase");
БазаДанных.Открыть(":memory:"); // Открываем временную базу в памяти

Запрос = БазаДанных.СоздатьЗапрос();

// Монтируем внешний DBF-файл как виртуальную таблицу
СтрокаПодключения = "CREATE VIRTUAL TABLE ТаблКлиентов USING dbf('" + СокрЛП(ПутьКФайлу) + "', 'CP866');";
Запрос.ВыполнитьЗапрос(СтрокаПодключения);

// Выполняем обновление данных без использования OLE DB и без учета CDX-индексов
ТекстUPDATE = "UPDATE ТаблКлиентов SET FIO='Петров Василий Пупкин' WHERE KOD=131559;";
Запрос.ВыполнитьЗапрос(ТекстUPDATE);

Преимущества метода:

Полное игнорирование поврежденных или несовместимых .CDX файлов.
Высокая скорость работы и поддержка SQL-синтаксиса SQLite.
Работа в разделенном режиме без необходимости выгонять пользователей из внешней программы.

Способ 2. Временный сброс флага индекса в заголовке DBF (Байтовый хак)

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

Проанализируем алгоритм выполнения:

Открываем файл DBF как бинарный поток (например, через ADODB.Stream).
Считываем байт со смещением 28 (байтовый адрес 0x1C).
Если байт равен 0x01, меняем его на 0x00 и сохраняем файл.
Выполняем необходимый SQL-запрос UPDATE или SELECT через ADO. Провайдер воспринимает файл как обычный DBF без индекса и успешно обрабатывает данные.
После закрытия ADO-соединения возвращаем байт 28 в исходное состояние (0x01).

Пример реализации сброса флага через ADODB.Stream:


Поток = СоздатьОбъект("ADODB.Stream");
Поток.Type = 1; // Binary
Поток.Open();
Поток.LoadFromFile(ПутьКФайлуDBF);

// Переходим к байту 28
Поток.Position = 28;
// Чтение и сброс флага CDX (0x00 - нет индекса, 0x01 - есть индекс)
// После изменения байта выполняется сохранение файла:
// Поток.SaveToFile(ПутьКФайлуDBF, 2);

Способ 3. Использование штатного объекта XBase

После снятия флага структурного индекса (способ 2) для модификации данных можно использовать штатный объект 1С 7.7 XBase, который при отсутствии флага 0x01 не станет искать .CDX файл:


ДБФ = СоздатьОбъект("XBase");
ДБФ.ОткрытьФайл(ПутьКФайлуDBF); // Индексный файл не передаем!

Если ДБФ.Открыта() = 1 Тогда
    ДБФ.КлючевоеПоле("KOD");
    Если ДБФ.Найти(131559) = 1 Тогда
        ДБФ.FIO = "Петров Василий Пупкин";
        ДБФ.Записать();
    КонецЕсли;
    ДБФ.ЗакрытьФайл();
КонецЕсли;

Особенности разделенного доступа и блокировок DOS/Clipper

При организации записи в сторонние DBF-файлы из 1С 7.7 важно учитывать специфику блокировок. Старые программы на DOS/Clipper и современные провайдеры Windows (OLE DB) используют разную логику блокировки файлов:

Clipper блокирует диапазоны байтов в старших адресах файла (в районе 1–2 ГБ).
Драйверы OLE DB используют системный механизм LockFileEx.

По этой причине OLE DB провайдер может не увидеть блокировки строки, установленной DOS-программой. Для исключения повреждения данных запись рекомендуется выполнять точечно с минимальной задержкой удерживания открытого файла или через транзакции компоненты 1SQLite.