Задумался сейчас как написать поведение подобно как в ODAC
т.е.
sql.text := 'select * from Table';
open;

И в dataset у нас лежит N записей, если всего записей больше чем N. Как только мы запрашиваем N+1 запись, автоматически тянутся еще N записей, т.е. в dataset у нас теперь 2N записей.
И есть св-во еще FetchAll, если его поставить в true и сделать open, тянутся все записи, как и сейчас, по умолчанию

> со свойством FetchNextRecords

с методом т.е.

т.е.
Open; // в dataset N записей
FetchNextRecords; // в dataset 2N записей
FetchNextRecords; // в dataset 3N записей

и св-во RecordsFetch есть еще. Оно и задает N.

Как такое можно сделать? Что почитать?
Или кто-то может уже делал?

пусть будет MSSQL
но можно и Access
да и oracle можно, с него тоже ADO все спрашивает, хотя там точно есть возможность спрашивать не все. ODAC же так и делает.

> OW  (17.11.2011 14:09:01)  [1]

Интернет, включая  ничего, включая Яндекс, есть немного про FetchNextRecord,
например что его нет в .NET

> OW  (17.11.2011 14:15:02)  [2]

Микрософт тоже не знает про FetchNextRecords и даже про FetchNextRecord

понятное дело.
Это надо добавить к ADO.
В наследнике, например.
А написать руками. Как в ODAC.

т.е.
ADO работает с Oracle, факт.
но затягивает все данные, все записи подходящие критерию
Можно ли, допустим, хотя бы для того же Oracle, написать наследника от TADODataset, который бы тянул данные порциями?

> OW ©   (17.11.11 14:46) [5]

Вы странного хотите. Хотите иметь высокоуровневый сервис, но с контролем за низкоуровневыми деталями реализации. Грамотно реализованная уровневая архитектура вам такого жульничества не позволяет, а вы бъётесь головой о стену собственного непонимания.

АДО ни с каким ораклом не работает. АДО работает с абстрактным ОЛЕ ДБ провайдером. АДО образует верхний слой абстракции, изо всех сил пытаясь предоставить вам максимально унифицированный и отвлечённый от деталейй реализации сервис.

Если вам нужны низкоуровневые детали, не пользуйтесь АДО. Используйте интерфейсы провайдеора. Вы, конечно, рискуете подвинуться рассудком от обилия деталей реализации, но вы, конечно, добьётесь своей, вне всякого сомнения, важной цели читать пренепременно по 27 записей.

Можно попытаться протелепать детали реализации, поиграться свойствами
CacheSize, CursorType, CursorLocation, выкурив сначала но ним всю документацию. Вы, скорее всего, добьётесь нужного поведения. Неизвестно как себя поведущего на другой версии МДАК, провайдера и сервера, -- но кого волнуют такие мелочи!

А можно, для начала, попытаться ответить на основной вопрос системотехники.

такого же не получится... в ADO есть асинхронная (+ порционная закачка), но она не регулируется через FetchNextRecords или подобное.
она закачивает асинхронно, все твоего желания. просто если будет обращение к еще недокачанному (например команда Last) то впадет в ожидание.
также есть серверный курсор, это как бы тоже самое, но без докачки, берется только то к чему обращаешься. и опять без твоего участия, по обращению к нужной записи (ну можно написать свою FetchNextRecords прокручивать, по Next, на нужное количество, но смысла особого в этом нет).

> в ADO есть асинхронная (+ порционная закачка),

Так он же этого не хочет, подай ему FetchNextRecords, хотя это  "Как только мы запрашиваем N+1 запись, автоматически тянутся еще N записей", ну или почти это.