RaFaeL-NNЕсть некая утилита, написанная давным давно на VFP 7.0. Конвертирует файлы из одного формата в другой
(...)
Переписать нельзя, так как то на чем пишется остальной проект не умеет работать с форматом dbase5, а работать надо обязательно напрямую, без odbc драйвера (есть прямые драйвера dbase4 и dbase3)
(...)
Когда то давно еще до разработки этого файла проект использовал odbc но на больших dbf (десятки мегабайт) просто "вешался". Напрямую через нужные индексы обратывается намного быстрее, один раз строится индекс, дальше всё быстро.
Несколько ошибок в логике

1. FoxPro тоже не умеет работать напрямую с форматом DBase5. Если VFP7 может открыть такие таблицы, значит это какой-то другой формат или Вы читаете только часть информации. Определить формат файла можно по значению его самого первого байта. FoxPro напрямую может работать со следующими форматами

0 байт Тип файла0x02 FoxBASE:0x03 FoxBASE+/Dbase III, plus no memo: 0x30 Visual FoxPro: 0x31 Visual FoxPro autoincrement enabled: возможно в VFP8 и старше0x32 Visual FoxPro, Varchar, Varbinary, or Blob-enabled: возможно в VFP90x43 dBASE IV SQL table files, no memo: 0x63 dBASE IV SQL system files, no memo: 0x83 FoxBASE+/dBASE III PLUS, with memo: 0x8B dBASE IV with memo: 0xCB dBASE IV SQL table files, with memo: 0xF5 FoxPro 2.x (or earlier) with memo: 0xFB FoxBASE

2. Индекс нужен для ускорения поиска. Однако у Вас стоит задача изменить формат файла. Это значит, что Вы будете сканировать ВСЮ таблицу. При любом раскладе. Вне зависимости от того, есть индекс или нет. А однократное сканирование занимает примерно столько же времени, сколько и собственно создание индекса

Тем не менее, если Вам нужен индекс, то это означает либо то, что Вы как-то "криво" написали алгоритм конвертации, либо сам по себе алгоритм достаточно специфический. Если этот код не очень большой, то приведите его здесь. Возможно, его можно оптимизировать и без необходимости в создании индекса. В этом случае и через ODBC будет быстро работать.

И еще. В какой среде происходит основная работа? Нельзя ли закачать DBF-файл напрямую в эту среду и там его конвертировать в нужный формат?

Если я правильно понял то, как Вы работаете, то получается следующее

1. Файл DBF конвертируется из формата VFP7 в формат Fox2x, при этом мемо-поля конвертируются в Character(254), а поля Double в Numeric(20,5)
2. Ваша программа, написанная на Clarion, берет этот файл формата Fox2x, строит по нему необходимые индексы и далее с ним как-то работает.

Честно говоря, не понимаю, почему Вы не можете через драйвер ODBC сделать выборку этой таблицы напрямую в Clarion и сохранить результат этой выборки на диск в виде той же таблицы DBF. Далее делайте с ней что угодно.

Последняя версия драйвер ODBC для FoxPro выпускалась для VFP6. Но в VFP7 никаких новых типов данных введено не было. Поэтому драйвер ODBC для VFP6 будет нормально работать с таблицами VFP7. Также был выпущен драйвер OLE DB для VFP9. Но это уже Вам виднее, может ли Ваша версия Clarion работать черз ADO.

И драйвер ODBC, и драйвер OLE DB для VFP можно найти на сайте Microsoft. Они распространяются бесплатно.

Во-первых, Вы не очень понимаете то, как работают выборки вообще, а, во-вторых, это все не имеет никакого отношения к тому, о чем я Вам говорю. Я ведь предлагаю Вам использовать ODBC не для штатной работы с таблицами, а для выполнения процесса конвертации .

Ну, смотрите, что Вы сейчас делаете

1. Конвертируете таблицу из одного формата в другой
2. Работаете с этой таблицей напрямую в Clarion

Я Вам предлагаю использовать ODBC только и исключительно для выполнения первого пункта примерно так

1. Скачали ВСЮ таблицу через ODBC
2. Сохранили на диске в нужном формате

Все. ODBC больше не нужен. Далее работаете с этой сохраненной таблицей напрямую через Clarion. При таком подходе у Вас вообще нет внешних (по отношению к Clarion) приложений. Ну, разве что, собственно драйвер ODBC. Вся "конвертация" выполняется только и исключительно средствами Clarion.

Вероятно, имеет смысл запускать эту процедуру, скажем, один раз в сутки. Ночью.

Мда... "Как все запущено" (с) Ну, начем с начала.

Не знаю, как для Вас, но для меня является аксиомой, что поддерживать одно приложение, проще, чем "зоопарк" различных приложений. При том, что в некоторых из этих дополнительных приложений разработчик мало что понимает. Это значит, что разработка механизма выполнения отчетов средствами только и исключительно Clarion с ODBC-драйверами предпочтительнее, чем использование "левой" программы для решения очень частной (промежуточной) задачи.

Настройки Windows. Здесь Вы опять заблуждаетесь, вероятно предполагая, что для создания соединения необходимо настроить DSN. Это не так. Не знаю, как это делается чисто технически в Clarion, но обязательно должен быть способ установки соединения с внешним источником путем прямого указания всех опция соединения, в том числе и драйвера. БЕЗ предварительно созданного DSN

RaFaeL-NNWindows у пользователя переставили - заново настраивать
Что настраивать? Вы хотите сказать, что Ваша программа на Clarion не требует никаких настроек? "Не верю" (с). Любая программа требует некоторых настроек при установке. А установка драйвера - это уже почти стандартная операция при установке приложений. А кроме собственно драйвера ничего устанавливать больше и не надо.

RaFaeL-NNДа и еще раз повторяю, это работает медленнее, чем конвертация в момент копирования файла! (...) пользователю сказали отчёты строить - он жмёт кнопку импорта, по свежим данным
Т.е. Вы хотите сказать, что построить индекс по всему файлу - это быстрее, чем сделать выборку из файла? Ну, если в выборку попадают все записи или большая их часть, то вероятно это действительно так. Однако создается ощущение, что Вы "ищите там, где светлее". У Вас сама технология создания отчетов явно "кривая". Вот зачем Вам для отчета ВСЕ данные таблицы?

В FoxPro есть такой механизм, называется Rushmore-оптимизация. Его основа - это индексы. При определенных запросах этот механизм используется, что позволяет существенно сократить время выборки. ODBC-соединение использует этот механизм. База Паруса, очевидно, должна иметь свои собственные индексы. Следовательно, если через ODBC-соединение выборка выполняется медленно, то возможны следующие варианты

1. Вы составили запрос, который не использует существующие индексы. Не оптимальный запрос.
2. Вы выбираете бОльшую часть данных из таблицы. Всю, или почти всю таблицу.

Ну, второй вариант не интересен. Тут Вам конвертируй или нет, особого выигрыша в производительности не добиться. Никакими способами. Да и не нужно этого. Хотите видеть вообще все? Ну, тогда ждите

А вот первый вариант требует, во-первых, знаний того, какие индексы в родной базе Паруса вообще есть, а, во-вторых, как эти индексы правильно использовать, чтобы получить ускорение. Задача достаточно творческая.

Другими словами, Вам нужно менять сам подход к интеграции с внешней системой. Вы выбрали не самый рациональный путь.

RaFaeL-NNпо свежим данным. Начальник ночи ждать не будет
Это вопрос обсуждаемый и не очевидный. Вы же не говорите о каких отчетах идет речь. Для большинства отчетов обновляемость раз в сутки вполне приемлимо. А для тех, где это неприемлимо, и объем выборок, как правило, небольшой. ODBC вполне себе будет быстро работать.

RaFaeL-NNда и лишние звенья это. Всё должно работать максимально просто и надёжно.
Вы почему-то не хотите примерить этот тезис на текущее положение дел. То, как Вы работаете сейчас. Разве внешнее приложение - это не "лишнее звено"? А разве сам факт наличия этого самого внешнего приложения не вносит элемент не надежности? Ведь Вы же не контролируете работу этого приложения. Оно для Вас "черный ящик".

Да хотя бы как Вы вообще определяете насколько "свежий" сконвертированный файл? Для каждого отчете делаете новую копию? А если пользователь запустил две копии приложения и "одновременно" вызвал один и тот же отчет? Вторая копия затрет содержимое первой?

Возникает куча вопросов по отслеживанию этой самой актуальности, разведения копий файлов по разным директориям, уникальность имен, удаление уже не нужных копий. В общем, довольно большое количество проблем необходимо решить. О надежности тут речи вообще нет. Подобная система работает до тех пор, пока есть кто-то, кто ее постоянно "пальцем придерживает". Именно что вручную следит за рядом настроек (переустановка Windows) и также "врукопашную" разруливает разнообразные конфликты.