Вот тебе типичное использование аdOpenForwardOnly курсора.

Shocker.ProНет. Догрузка данных происходит асинхронно в другом потоке,Вообще-то, как раз синхронно.Shocker.ProТо есть ты просто не замечаешь этой догрузки.В асинхронном режиме, он ее очень даже хорошо заметит :)

И вообще, синхронность и асинхронность работы это вопрос намного более сложный и долгий. Не стоит его примешивать к учебнику по курсорам.

Shocker.ProWhite OwlShocker.ProНет. Догрузка данных происходит асинхронно в другом потоке,Вообще-то, как раз синхронно.
О, черт.
Опять придется флеймить с доказательствами того, что Open возвращает управление до окончания фактической передачи данных?Наверное.... Уж коли внимательность подводит, то придется флеймить.
Open в синхронном режиме возвращает управление когда сервер выдаст хоть что-нибудь. В случае успешной обработки запроса это будет первая строкя первого резалтсета. После этого, подготовленные данные первого резалтсета сидят в буфере на сервере и по каждому MoveNext сервер отдает очередную строку. Сервер в это время, ничего кроме отдачи строк из подготовленного резалстета не делает. Обработку запросов от других коннектов мы сейчас не рассматриваем. Когда клиент даст команду NextRecordset сервер проснется и продолжит выполнение командного пакета подготавливая следующий резалтсет. Клиент в это время будет сидеть и ждать. Как только сервер подготовит следующий резалтсет, он отпустит клиента из режима ожидания и тот снова начнет выбирать строки через MoveNext.

А в асинхронном режиме все несколько по другому. Послав Open клиент сразу же продолжает работать. Клиент не будет ждать пока сервер разберется с таблицами, индексами и связями. Но это так же означает, что клиент не сможет сделать успешный вызов MoveNext, потому что сервер еще не подготовил резалтсет. И клиент, прежде чем начнет получать данные, должен будет сидеть в цикле типа:
И только когда State станет равным adStateOpen ты сможешь сделать успешный MoveNext.
Причем MoveNext тоже будет возвращаться сразу же, не дожидаясь пока данные реально пройдут по сети и лягут в клиентский объект. В это время State будет равным adStateFetching.


Синхронность и асинхронность в применении к ADO (и вообще ко всем интерфейсам баз данных) означает что команды общения с сервером либо будут, либо не будут ждать ответа от сервера прежде чем передать управление следующей строке программы.

Shocker.ProЕдинственное, что противоречит моему пониманию происходящих процессов, это твое "подготовленные данные первого резалтсета сидят в буфере на сервере и по каждому MoveNext сервер отдает очередную строку" . Я не уверен, что это происходит именно так, что данные не подкачиваются, пока я, скажем, ушел в затуп и вообще не делаю MoveNext. Но доказать это не могу, надо провести серию экспериментов.Это и верно и неверно одновременно :)
С точки зрения реальной нагрузки на сеть, клиент действительно чаще всего перекачивает записи по нескольку штук за раз. Если ты заглянешь в настройки интерфейсного драйвера ты возможно сможешь найти там что-нибудь типа Fetch Array Size. Но большинство драйверов не позволяют контролировать размер пакета или просто не афишируют это свойство в настройках доступных рядовому админу.
А с точки зрения VB* выкачивает драйвер строки пачками или по одной - никакой разницы нет. С уровня VB ты никогда не сможешь добраться до драйверного буфера и как-либо его использовать.
Принцип тут тот же что и с буферизированым чтением из файла. Осознание того факта что харддрайв не дергается за каждым байтом а читает данные покластерно, греет душу, но не заставляет тебя менять алгоритм побайтового чтения файла на блочный.

Совсем другое дело синхронный или асинхронный доступ к БД. Использование того или другого означает что ты будешь писать программу в двух разных стилях. Поэтому я и возмутился на необдуманное использование слова "асинхронный".

Shocker.ProWhite OwlС точки зрения реальной нагрузки на сеть, клиент действительно чаще всего перекачивает записи по нескольку штук за раз. Если ты заглянешь в настройки интерфейсного драйвера ты возможно сможешь найти там что-нибудь типа Fetch Array Size. Но большинство драйверов не позволяют контролировать размер пакета или просто не афишируют это свойство в настройках доступных рядовому админу.
Ну тут у меня было непонимание только в одном: предположим, я сделал разок MoveNext и ушел в затуп. Будет ли в это время происходить докачка?Ответ: Возможно.
Я не могу дать более точного ответа. Это все зависит от конкретной версии интерфейса и реализации интерфейсного драйвера.
До тех пор пока ты не сделаешь очередной MoveNext данные точно не попадут в память твоей программы, но попадут они в память интерфейсного драйвера на клиентской машине или нет - без копания в исходниках драйвера сказать обычно нельзя.

Shocker.ProПри Forward-курсоре я начинаю чтение и обработку данных и вдруг бросаю (пользователь прервал процесс). Делаю на рекордсете и на комманде всякие Cancel, Close, Nothing, однако, пока эта сволочь полностью не заберет недобранные данные с сервера - управление мне не возвращается. Особенно заметно при работе через интернет - если данных было много, приложение затупливает на несколько секунд и трафик виден. Если данных при тех же условиях было меньше или дело происходит в локалке - отменяется гораздо быстрее.Да, это возможно. Опять таки повторюсь: все зависит от конкретной реализации интерфейса. Вполне возможно что клиентский драйвер действительно будет тянуть остатки резалтсета даже если его отменили. Стандартов на реализацию этого момента нет и каждый делает как ему кажется лучшим. В конце-концов "выбрать все и забыть" тоже можно считать "отменой".

А вообще, смотри как организуется обмен по TCP - одна сторона пихает в свой конец туннеля, потом читает, снова пихает, снова читает... Если сервер считает что он должен запихать в туннель вот такой-то объем данных, клиент не может его прервать и сказать "хватит". В принципе не может. Только если сервер посылает данные блоками и между каждым блоком слушает "а не просят ли меня остановится", только тогда возможно прерывание посылки... И я совсем не уверен что подставь_свою_СУБД делает именно это.