Почему VFPOLEDB записывает некорректную кодировку после первой записи и как это исправить?

← На главную

При интеграции 1С с внешними системами часто возникает необходимость записи данных в формат DBF. Если файлы активно используются другими программами (например, написанными на FoxPro), стандартный объект 1С XBase может не подойти, так как он часто требует монопольного доступа для корректной записи. В таких случаях программисты используют ADODB и драйвер VFPOLEDB. Однако здесь можно столкнуться с коварной ошибкой: первая запись в таблицу проходит успешно, а все последующие превращаются в «кракозябры».

В этой статье мы подробно разберем, почему возникает эффект «порчи» кодировки, проанализируем механизмы работы драйвера Visual FoxPro и найдем проверенное решение проблемы.

Анализ исходной ситуации

Рассмотрим типичный сценарий. Для записи используется объект ADODB.Connection. Код инициализации соединения выглядит следующим образом:


Connection = Новый COMОбъект("ADODB.Connection");
Соединение = ("Provider=vfpoledb;   
             |Data Source=""" + Путь + """;
             |Extended Properties=DBASE IV;
             |Codepage=1251;");
Connection.Open(Соединение);

Проблема проявляется странным образом: при первом запуске алгоритма строка «ПРУТОК ДКРНП Л63» записывается идеально. Но при повторном выполнении того же кода без перезапуска сессии 1С или при записи второй строки в том же цикле данные превращаются в «IDOOIE └EDII E63». Это классический признак того, что драйвер теряет контекст кодовой страницы или некорректно интерпретирует Unicode-строку из 1С.

Разбор технических причин ошибки

Выясним причину такого поведения. Существует несколько факторов, влияющих на работу VFPOLEDB с кириллицей:

Версия драйвера и Service Pack. Драйверы FoxPro 9.0 без установленного SP2 имели внутренние ошибки в управлении кэшем метаданных. При первом обращении драйвер считывает заголовок DBF, а при последующих может использовать закэшированные настройки, которые по умолчанию сбрасываются в системную кодировку ANSI (часто 1252 вместо 1251).
Кэширование метаданных в Connection Pooling. Когда мы указываем в Data Source только путь к каталогу, драйвер инициализирует сессию для всей «базы данных» (папки). При записи в конкретную таблицу механизм ADO пытается сопоставить типы данных. Если в 29-м байте заголовка .dbf файла указана кодировка, отличная от системной, возникает конфликт трансляции.
Взаимодействие с системным реестром. Старые компоненты доступа к данным часто полагаются на настройки NLS (National Language Support) Windows. Если в реестре соответствие кодировок настроено некорректно, драйвер может подменять символы.

Шаг 1: Настройка строки соединения и выбор драйвера

Как показала практика, одной из главных причин является версия самого провайдера. Если установлена только 9-я версия, попробуйте установить драйвер Visual FoxPro 8.0. Они могут сосуществовать в системе, но 8-я версия иногда ведет себя стабильнее с устаревшими форматами dBase IV.

Проанализируем правильный подход к формированию строки соединения. Вместо того чтобы указывать только путь к папке, попробуйте передать полный путь к файлу или использовать обновленные параметры. Также крайне важно добавить Locale Identifier.

Рассмотрим улучшенный вариант инициализации:


Соединение = "Provider=vfpoledb;
             |Data Source=" + ПутьКФайлу + ";
             |Mode=ReadWrite;
             |ProcessEncoding=True;
             |Locale Identifier=1049;";

Здесь Locale Identifier=1049 явно указывает драйверу использовать русскую кодировку, что минимизирует риски «угадывания» страницы провайдером.

Шаг 2: Правильное управление объектами ADO

Одной из причин порчи данных при второй записи является некорректное освобождение объектов Command и Recordset. Если объект не уничтожен явно, OLE DB может удерживать блокировку или состояние трансляции. Разберем правильный цикл записи:


// Создаем соединение
Connection = Новый COMОбъект("ADODB.Connection");
Connection.Open(СтрокаСоединения);

// Подготавливаем команду
Command = Новый COMОбъект("ADODB.Command");
Command.ActiveConnection = Connection;

// Текст запроса (лучше использовать параметры, чтобы избежать проблем с кавычками)
Command.CommandText = "INSERT INTO MyTable (NameField) VALUES ('" + ЗначениеИз1С + "')";

// Выполняем запись
Command.Execute();

// Обязательно освобождаем ресурсы сразу после записи!
Command = Неопределено;
Connection.Close();
Connection = Неопределено;

Важный нюанс: Если вы выполняете запись в цикле, попробуйте переоткрывать соединение на каждой итерации, если быстродействие позволяет. Это гарантирует сброс кэша драйвера.

Шаг 3: Проверка заголовка DBF-файла

Если программные методы не помогают, нужно проверить сам файл. За кодировку в DBF отвечает 29-й байт (Code Page Mark). Для кодировки Windows-1251 там должно стоять значение 0xC9 (201 в десятичной системе), а для DOS 866 — 0x65 (101). Если там стоит 0x00, драйвер будет вести себя непредсказуемо.

Рассмотрим ситуацию, когда программа-источник (на FoxPro) работает в 866 кодировке. В этом случае в строке соединения 1С бесполезно указывать Codepage=1251. Вам необходимо либо перекодировать строку в 1С перед отправкой, либо настроить драйвер на работу с OEM страницей:


// Пример принудительной установки кодовой страницы через команду FoxPro
Command.CommandText = "SET CPDIALOG OFF"; // Отключаем диалоги выбора кодировки
Command.Execute();
Command.CommandText = "SET COLLATE TO 'MACHINE'";
Command.Execute();

Итоговое решение проблемы

Проанализировав опыт решения данной задачи, можно выделить два ключевых действия, которые помогают в 90% случаев:

Смена целевого пути. Если драйвер при указании пути к каталогу (Data Source=C:\MyBase\) начинает путаться в кодировках таблиц, укажите путь напрямую к файлу или убедитесь, что в папке нет других файлов с противоречивыми заголовками.
Обновление или откат драйвера. Установка VFPOLEDB версии 8.0 часто решает проблемы, которые возникают в версии 9.0 при работе с кириллицей в многопользовательском режиме.

Помните: 1С передает строки в формате Unicode. Драйвер VFPOLEDB является «прослойкой», которая транслирует этот Unicode в однобайтовую кодировку DBF. Если первая запись успешна, значит, механизм трансляции работает, но «ломается» из-за кэширования состояния. Явное закрытие соединения и использование параметра Locale Identifier — ваши лучшие инструменты в борьбе за чистоту данных.