Если речь идет о файлах DBF, созданных в приложениях под DOS, то можно попробовать использовать старые драйвера

{Microsoft dBase Driver (*.dbf)}

Примеры строк подключения можно посмотреть здесь

Connection strings for DBF / FoxPro

Дело в том, что если кодовая страница файла DBF не указана явно, то FoxPro предполагает, что данные в нем записаны в текущей кодовой странице среды FoxPro.

Весь вопрос в том, какая именно кодовая страница среды FoxPro устанавливается. Точнее, откуда она берется.

В русскоязычной локализации Windows при использовании старых драйверов для DOS-версий будет использоваться 866 кодовая страница. Что, в данном случае, и требуется. А для Windows-версий (Visual FoxPro) используется кодовая страница 1251.

Вы пробовали открывать в каком-нибудь текстовом редакторе обычные текстовые файлы, созданные в DOS-кодировке? Текст получается совершенно не читаемый. Почему? Да потому, что текстовый редактор предполагает, что весь текст имеет вполне определенную кодировку. Ту, в которой он сейчас и работает.

Если редактор "продвинутый", то у него есть пункт меню вроде "Выбрать кодировку". Вы выбираете этот пункт и текст сразу становится "читаемым". Почему? Потому что вы явно указали как именно надо читать этот текст.

Обратите внимание на два момента:

1. Есть некий способ чтения "по умолчанию"
2. В случае явного указания, способ чтения меняется, если это возможно

У текстового файла нет признака, по которому текстовый редактор мог бы однозначно определить как читать данные, поэтому пользователь вынужден указывать это вручную. Для файлов DBF такой признак может быть записан в 29 байте заголовка. Это и будет являться явным указанием сменить способ чтения, если "текстовый редактор" на это способен .

Если изначально текстовый файл был пустым, то совершенно не важно, какой именно способ чтения "по умолчанию" используется в данном текстовом редакторе. Записанный и сохраненный текст будет прекрасно читаться при повторном открытии. Ведь и при записи и при чтении был использован один и тот же режим "по умолчанию".

Именно поэтому 1С прекрасно записывает/читает данные из DBF-таблиц не "заморачиваясь" с установкой признака кодовой страницы. Ведь и чтение и запись происходит в одном "текстовом редакторе" в одном режиме "по умолчанию".

А вот если запись произошла в одном текстовом редакторе, а чтение осуществляется в другом, то вот тут-то проблемы и начинаются. Ведь у каждого текстового редактора используются собственные режимы чтения по умолчанию.

Это значит, что у нас есть две принципиальные возможности.

1. Каким-то образом явно указать режим чтения данных, если у текстового редактора есть возможность выбора режимов чтения
2. Выбрать такие текстовые редакторы, которые имеют одинаковые режимы чтения "по умолчанию"


Возвращаясь к файлам DBF, вопрос заключается в том, что именно выступает в качестве "текстового редактора" для чтения DBF-файлов. Как следствие, какой именно алгоритм "по умолчанию" будет использован.

Если данные беруться из таблиц через ODBC или ADO, то в качестве "текстового редактора" выступает драйвер ODBC или ADO. Даже не программа! А именно и только драйвер .

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

Новые, соответственно в кодовой странице Windows или с учетом указанного признака кодовой страницы, если он указан явно.

Поскольку вы подключаетесь к файлам DBF, которые не имеют признака кодовой страницы, то единственным способом решения для вас становится выбор соответствующего драйвера. Что я вам и предложил.

PS: Прежде, чем задавать вопросы дальше, настоятельно советую сначала попробовать использовать разные драйвера. Несколько минут экспериментов лучше для понимания, чем несколько часов теории.

0x03 FoxBASE+/Dbase III plus, no memo

То, что 29 байт не заполнен, говорит о том, что, скорее всего, использовалась DOS-кодировка. А старые драйвера входят в поставку операционной системы "по умолчанию". Ничего специально устанавливать не надо.

По приведенной ссылке могли бы еще заметить и ряд других драйверов для работы со старыми DOS-таблицами. Так что, никаких проблем быть не должно.

The Dim!На обоих Win2k3 EE Eng + MUI
Скорее всего, проблема именно в этом. Т.е. в том, что это английская локализация. В этом случае, текущая кодовая страница DOS будет 437. Если есть возможность, попробуйте проверить закачку на машинах, где установлена русская локализация Windows.

Если не пытаться устанавливать признак кодовой страницы в файлах DBF, то надо попробовать делать конвертацию по факту получения. Т.е. уже средствами самого SQL-сервера.

Как вариант: закачку делать во временные таблицы, у которых все символьные поля явно объявить с нужным COLLATION. А потом попытаться пербросить данные из этой временной таблицы в другую, с нужной кодировкой.

Правда, не уверен, что SQL сделает автоматическую трансляцию кодовых страниц. Я такое ни разу не пробовал.

Возможно, задачу перекачки данных будет проще решить через Integration Services. Кажется, там есть возможность явного указания кодовой страницы.

Я попробовал поискать на этом же сайте, но в форуме по MS SQL (вопрос-то о нем, а не о FoxPro). Оказалось, там очень много уже чего понаписали на эту тему. Практически все варианты перебрали здесь

/topic/180672