Никто и никогда не будет закачивать ВСЮ таблицу на клиента. Это бессмысленно, поскольку ни один "вменяемый" человек просто не способен визуально просмотреть миллион записей. Да и не нужны они пользователю. Как правило, пользователь работает с крайне ограниченным набором данных. Например, за последний день, неделю, ну, или месяц.

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

Именно из подобных соображений и делаются выборки. Т.е. выборки с дополнительным условием WHERE.

Физически, выборки можно оформить следующим образом

1. Программный код (файл PRG).
1.1. Напрямую в методе формы
1.2. В файле QPR (это обычный файл PRG с измененным расширением. Наличие контейнера базы данных для него не обязательно)
1.3. Прописать в свойстве Grid.RecordSource, если RecordSourceType=SQLStatement

2. Local View (требует наличие контейнера базы данных)

3. Использование класса CursorAdapter

Какой способ лучше? Ну, любые способы имеют достоинства и недостатки. Все зависит от решаемой задачи и личных предпочтений программиста.

Программный код (вне зависимости от выбранного варианта) потребует дополнительного программирования, если потребуется изменения, внесенные в Grid, перенести в таблицу-источник. Т.е. придется писать много кода. Но, с другой стороны, процессы чтения и модификации под полным контролем программиста и нет "непонятных" процессов, выполняемых "автоматически"

Local View и CursorAdapter позволяют автоматизировать процесс переноса изменений из выборки обратно в таблицу-источник

Local View имеет ограниченную функциональность. Подходит, скорее, как инструмент обучения, поскольку при сложной логике модификации данных может не справится с требуемым функционалом. Однако именно как инструмент обучения практически идеален. Достаточно просто понять "кто на ком стоял"

CursorAdapter - относительно сложен в понимании, однако дает бОльшую "свободу маневра" для программиста по сравнению с Local View

q1w1e1сомневаюсь, что выполняется весь запрос при SQLStatement, вроде как там подкачка по мере необходимости, когда курсор сдвигается, если люди желают видеть весь список записей а потом ввести параметры выборки, а не вначале параметры выборки, а потом список...но это опять отвлечение..., т.е. получается отказаться от QPR,SQLStatement и открывать всю таблицу
Любой, т.е. абсолютно любой, из перечисленных ранее методов, в конце концов сводится к выполнению команды Select-SQL. Вне зависимости от того, как именно она "скрыта" или во что "обернута". Это значит, что вне зависимости от того, будет ли эта команда выполнена через файл QPR, прописана в SQLStatement или "обернута" в CursorAdapter общие принципы выполнения от этого не изменятся. Запрос выполняется сразу и целиком. Нет инструментов, чтобы "фетчить" (осуществлять подкачку "по требованию") запроса к DBF-таблицам.

С другой стороны, а зачем Вам вообще запрос? Почему Вы хотите отказаться от прямого обращения к DBF-таблицам? В чем проблема-то? Вот при просмотре DBF-таблиц будет скачано на клиента только то, что отображается (ну, и индекс, конечно). Все, как Вы и хотели...

Основная идея запроса - это выбрать (запросить) только то, что необходимо. Определенные поля из определенных записей. Если Вам необходима вся таблица, что зачем запрос?