Юзаю триалы PostgresDAC. Те же яйца вид сбоку. И та же трабла. Может это проблема на концетпуальном уровне. Шо я только что сказал? Сам не понял.

фффф...То есть, вывод в одном датасете всех записей мне представляется излишним. Постраничная же навигация (с ограничением одновременно отображаемых записей) через FETCH FORWARD/FETCH BACKWARD или LIMIT .. OFFSET - делается и без этого.
тут я не понял. Где делается? Кем? Суть топика как раз сводится к тому, что компонентами них.. не делается. Возможно, Вы имеете в виду такую реализацию в своем приложении. Писать компоненты прямого доступа - кул. Яж на это не способный (
фффф2) если в объявлении курсора запрос с группировкой/сортировкой, то для курсора сервер вынужден будет выбрать все данные. Если десяток пользователей начнет такие миллионные выборки делать одновременно - туго серверу придется.
До сих пор разговор шел про разгрузку клиента и сети. Мне необходимо, чтобы после выполнения запроса на сервере я увидел данные. Реально после выполнения запроса я еще жду некоторое количество времени (зависит от размера выборки) пока все данные не закачаются на клиента. Это сакс.

Vzhikв файле известных багов....Zeosa...

6. If you are using dbgrid, all the records will be fetched because of a call to recordcount (in scrollbar). You can avoid this behavior if you turn on the Filtered property. In this case you can achieve fast open even on bigger resultsets.

у меня пока нет большой таблицы чтоб проверить... Но если всетаки свойство Filtered установить? интересен эффект!
Zeos 6.1.5-stable build at 2004-04-29 07:03:04. Запрос на полтора миллиона записей (записи довольно - таки широкие). Открытие ZReadOnlyQuery занимает полторы минуты. Система 2 раза успела сообщить, что увеличен файл подкачки. В процессе открытия на машине работать невозможно. Переключение Filtered не дает никакой реакции. Грид даже не ставил, ни на что не завязанный набор данных (может надо было:-)))?)
Естественно, открытие таких больших наборов данных - недостаток и в корректно построенном проекте оно не должно осуществляться. Всегда можно разбить на группы - подгруппы, выводить логически законченными кусками... но даже в этом случае fetch всех записей на клиента весьма раздражает. Привыкли к тому, что любой запрос в оракле - это курсор и клиент ждет только выполнения запроса + выборки первых нескольких записей.
2 фффф: переделывать проект под постраничный вывод данных во всех грида я не буду даже обсуждать. Это корректно для web - проекта, но не для GUI - приложения.

2 фффф (мысли вслух):
Я понимаю ситуацию так: WITH HOLD эмулирует версионную модель работы, т.е. курсор кэшируется на сервере. Потому и тормозит. Если отбросить этот режим работы, т.е. использовать WITHOUT HOLD, то единственным возможным вариантом поведения клиента будет переоткрытие курсора после Commit с позиционированием на... например на номер записи в курсоре. Насколько я понимаю (а я часто ошибаюсь), то именно так происходит в других серверах при CommitRetaining.
Решение данной проблемы в FB - WITHOUT HOLD и долгоиграющая транзакция на чтение, благо количество транзакций на сессию там не ограничено. В Oracle похоже существенно оптимизировали кэширование курсора при его открытии и все курсоры открываются по умолчанию с WITH HOLD.

ЗЫ: побейте меня ногами, если всё вышеперечисленное - ересь.