ADOTable

[geb2010]

Каким образом можно перегнать данные без визуальных компонентов?

в примере 80000, а может быть до 200000

[Stilet]

Каким образом можно перегнать данные без визуальных компонентов?

Что такое визуальные компоненты ты знаешь? Label, Memo и т.д.
короче говоря создавай переменку типа Array of тип поля. Сразу через SetLength() задавай ей размерность до цикла, и в цикле переписывай в массив данные. В цикле не должно быть никакого вывода на экран.
Однако выигрыш в скорости будет невелик, поэтому так никто не делает, а если и делают, то такие программы становятся сущим адом для пользователей.

[geb2010]

Если не использовать ADOTable, то как обратиться к файлу, в котором данные в формате *.DBF, чтобы читать в ARRAY? У меня на экран при чтении ничего и не выводится.

[Stilet]

чтобы читать в ARRAY?

Пффф...
Давай ты всетки обьяснишь зачем тебе читать в массив. Иначе мне просто нечего сказать.

[geb2010]

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

[Stilet]

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

[geb2010]

Ну почему, предложи свой путь решения, я буду очень тебе признателен

[Stilet]

Чтобы предложить путь нужно знать ТЗ.
когда я обрабатывал данные снятые датчиком с обточки колесной пары (а это порядка миллиона точек) я не делал никаких циклов и по четко поставленному заданию использовал СУБД, которая сама аналитику и высчитывала.
Ты подробности опиши как можно подробнее. Что. Зачем. Когда. Откуда и куда. Ничего же не известно кроме того что у тебя есть DBF ник, откуда ты что-то хочешь получить. Для чего и почему остается только догадываться.
По факту при надлежащих индексах СУБД одним запросом может дать тебе нужный результат, а ты циклы решил городить для перемещения данных.
Запросами надо решать эту проблему, или писать свой компонент, который из DBF сумеет сразу весь файл считать в память.

[geb2010]

На оборудовании стоят датчики, которые опрашиваются контролером, с которого данные передаются на компьютер и программа записывает их в DBF файлы.
Все это сделано сторонней организацией, ни какой документации на оборудование нет, кроме как посмотреть текущие графики в программе на компе. Одновременный просмотр за несколько месяцев программа не позволяет и тем более провести анализ. Поэтому и возникла необходимость написать свою программу, которая позволяла все это сделать. Построение графиков и анализ уже написаны и все работает, но загрузка файлов в программу медленная и в основном из-за функции ADOTable.Next, наверно эта функция не просто увеличивает индекс, а производит поиск с начала файла. Думаю так потому, что в начале идет быстрое считывание (примерно тысяч до 10) , а потом все медленнее и последние записи (при 200000) считываются где-то за 5-10 секунд. Думал, что есть способ как-то иначе считывать данные файла в массив, поэтому и написал в форум.
Эти файлы не принадлежат одной СУБД, просто отдельные файлы.

[Stilet]

наверно эта функция не просто увеличивает индекс, а производит поиск с начала файла.

Ошибаешься.

Эти файлы не принадлежат одной СУБД, просто отдельные файлы.

А они и не должны кому-то принадлежать.
Однако мы на заводе такие вещи решали с помошью FoxPro, который и был выбран в качестве СУБД для обработки DBF файлов.
Создавались индексы для ускорения работы (например нахождения точек для стачивания), а потом запросом за миллисекунду подбирались данные.
Никакого цикла тут не надо, тебе нужно все делать запросами.
В винде кстати есть провайдер для работы с DBF через Query.
Опять таки описанная тобой информация вообще ни о чем не говорит что нужно делать с данными. Поэтому и ответ такой.