В моих ODBC-шных источниках данных оформлен надлежащим образом (Пользовательский DSN) источник «Загранпаспорта» - папка с db-файлами PARADOX(DOS,866).
Выборка данных из одного такого файла (kart_ovr.db) срабатывает изумительно:

STORE SQLCONNECT('Загранпаспорта', 'ТЕХНАРЬ') TO gnConnHandle
= SQLSETPROP(gnConnHandle, 'asynchronous', .F.)
= SQLEXEC(gnConnHandle, 'SELECT * FROM kart_ovr', 'My_kart_ovr')
= SQLDISCONNECT(gnConnHandle)

Да вот беда – мне очень надо, чтобы результирующий курсор ‘My_kart_ovr’ имел исходную кодировку (866), а он отображается в режиме 1251. Никакие обратные преобразования (типа CPCONVERT) не помогают. Устанавливать CODEPAGE=866 в файле config.fpw – тоже пробовал. Ничего не выходит.
Единственный способ, который дает желаемый результат, выглядит таким образом:

1) вытягиваю данные путем импорта (хоть через VFP7, хоть через Access)
2) сохраняю их в виде dbf-таблицы.
И вот в этой-то таблице и соблюдается исходная кодировка.
А мне надо этот процесс автоматизировать, чтобы вручную НЕ кликать по интерфейсным кнопкам Мастера импортирования, особенно для обработки множества файлов.
Можно ли сохранить кодировку в процессе ODBC-шного получения данных?

Пробовал и SET NOCPTRANS TO
Ни фига не получается. Эта команда корректно срабатывает, например, при такой последовательности:
USE какой-нибудь dbf-файл
SET NOCPTRANS TO какое-нибудь поле этого файла
select поле1, поле2, поле3, ... from этот dbf-файл
Т.е. SET NOCPTRANS TO устанавливается на УЖЕ ДОСТУПНОЕ поле
А при ODBC-импортировании - какой уж там доступ! Доступ получается уже после выполнения SQLEXEC, а кодировка после этого - уже неуправляема...

Copy to <NewName> AS 866 тоже не проходит, данные остаются без изменения. Это я уже проверил неоднократно.
To ВладимирМ:
Необходимость сохранения кодировки следующая.
В одной из исходных таблиц поле дата_рождения закодировано весьма сложным способом, а сам способ кодирования использует (жестко привязан к) 866-кодировку. Я раскодировал это поле (вычислил алгоритм). Все вроде удачно получается. Но при обновлении информации (получаю db-файлы из того же источника) приходится снова импортирование делать через Визард, т.е. - вручную, в то время как вся остальная часть программы обработки у меня автоматизирована. Получается, бульдозер буксирует самолет. Хочу автоматизировать и процесс импорта.
ЗЫ. Привязать процесс раскодирования к 1251-кодировке не получится - многие 866-символы (непечатаемые) трактуются 1251-кодировкой ОДНООБРАЗНО, что искажает информацию. Для сравнения: выборка SELECT DISTINCT ... по этому полю в 866 кодировке дает набор из 22142 значений, а при 1251-кодировке - только 8140 значений. Налицо потеря информации за счет однообразной трактовки РАЗНЫХ символов.

Да я бы давно уже выложил данные, да объем слишком большой. А вычленить часть парадоксовских данных нечем, нет у меня собственно Парадокса на компе. Можно, разве что путем двойного ручного импорта db-->dbf(выборка части данных)-->db, но при этом нельзя ручаться за ПОЛНУЮ идентичность конечного и исходного варианта данных. Щас помудрю в течение обеденного перерыва, может, что-нибудь придумаю.

На приложенном внизу рисунке видно, что курсоры, полученные разными путями из одного исходного db-шника, по-разному отображают данные. К примеру, Q3 – получен упомянутым в 1-м посте импортированием через ODBC. А Q4 – получен вручную через Wizard-импорта. Видно, что данные поля dr для одних и тех же значений поля kod выглядят совершенно по-разному, и более того – РАЗЛИЧНЫЕ значения поля dr (см. Q4) приводятся к совершенно ОДИНАКОВЫМ значениям (см. Q3) - одинаковость проверял на уровне ASC-кодов. Надо ли доказывать, что копирование через COPY ... AS ..., примененное к Q3 уже не вернет исходного разнообразия значений (как в Q4)?
Короче, пришел к выводу, что имеющимися в моем распоряжении средствами никак не удастся решить мою проблему. Нашел на одном из сайтов паскалевский исходник для низкоуровневого доступа к db-файлам – «переведу» его на Фокс и включу в свою программу обработки – по идее, должно пойти. Жаль, что окольными путями приходится действовать :((