Упустил момент, когда все сюда перебрались.. Потому повтор вопроса из другого форума.
В Pb8.04 по сравнению с Pb6.5 существенно изменилась не в лучшую сторону динамика увеличения времени отбора данных с возможностью остановить отбор и без неё. Как известно, это делается при скриптировании события RetrieveRow.
Время отбора для Pb6.5 (с возможностью прерывания) растет, во всяком случае, не более, чем линейно с количеством отобранных строк, что понятно и вполне приемлемо.
То же время для Pb8.04 растет... не буду говорить, что экспоненциально, но уж во всяком случае, не линейно вместе с количеством строк.
Скажем, на насыщенной строке (много столбцов, выпадающих списков и т.д.) разница на 60 000 записях полминуты и 7,5 минут для Pb8.04, а на 900 000 строк 6 минут первый отбор, а второй я остановил после двух часов, причем, не было и половины. Динамика процесса не предполагала окончания отбора в этом месяце..:-))) При этом память на данные - по моим впечатлениям - Pb804 использует экономнее...
Рабочая станция: чипсет Springdale, P4 2,4 Гц, памяти двухканальной DDR400 1G, WINXP SP2, все дела...
Фигня-с, однака - с... О целесообразности подобного отбора вопрос не ставится. Просто шеф ТАКОГО ПОВЕДЕНИЯ ПРОГРАММЫ не хочет.
У меня нет PB9 - никто не знает, как там обстоит дело в этом отношении? А может, и по поводу Pb8.04 какие-нибудь комментарии будут?

Надо заметить - повторюсь - из-за изменения "Memory Management routines" Pb8 корректно выгружает данные лишь начиная с версии Pb803. Потому использование трёх первых релизов этой версии для серьёзных задач, судя по всему, нецелесообразно.
Для cbusel:
Как правильно процитировал help eddi, даже просто комментарий в retrieverow включает этот механизм асинхронности при отборе данных.. Конечно, я попробовал оставить только комментарий (там еще что-то было) - эффект тот же..
Для Филиппа:
Несомненные глубокие знания по обсуждаемым вопросам конечно позволяют порезвиться, но Вам не кажется, что это мальчишество? Почему бы просто - (и попроще - в соответствии с KISS :-)))) не объяснить, раз уж взялись? Каюсь, я и сам резвился (в других областях:-)))); удовольствие минутное, зато авторитета не прибавляет. Просто разговаривать перестают. Авторитета прибавляет терпеливое и понятное окружающим разъяснение вопроса.

Опаньки!!! Действительно, setredraw() было выставлено в true. Правда, и в Pb6.5 также было true. При выставлении в false всё прет быстро и процесс не замедляется!!
Беда только, что на экране нету строк отображаемых. Выход: включать и выключать отрисовку каждые n записей, где n по усмотрению...
Сделал так (n=1000):

RetrieveStart:
this.setredraw(false)

RetrievwRow:
if mod(row,1000)=0 then this.setredraw(true)
if mod(row,1000)=1 then this.setredraw(false)

RetrieveEnd:
setredraw(false)

Тогда после каждой тысячи записей задержка на полсекунды, но общего замедления нет. И строки отображаются - со всеми вытекающими. Типа пролистнуть можно
Для с127:
Мои благодарности!

Ошибочка... конечно,
RetrieveEnd:
this.setredraw(true)

"Понять это невозможно - принять только..."
Тот, кому мы поставляем продукт, хочет, чтобы:
1) Result set был целиком и как можно быстрее на клиенте , потому Retrieve.AsNeeded не годится... да и неудачное дерганье за scrollbar в этом режиме всё равно вызывает отбор до конца.. и много других неудобств..
2) при нажатии кнопки "Отобрать" была быстрая реакция системы - не просто голый экран с часиками, но видна динамика - КАК это происходит. Окошка с бегущим числом записей недостаточно. А так всё дышит, scrollbar (хотя и дискретно) бежит , строки видны .
3) можно было это остановить в любой момент - когда захочется.
Особенно это полезно, когда анализируют возможности системы вообще. Ведь и в конкурсах надо выигрывать - не только работать в ней..:-)))
Большое неудобство в том, что либо retrieveRow либо есть, либо нет. Как бы включение этого в настроку вынести... А так приходиться статично класть на окно либо dw с ним, либо без него.:-((( Два объекта сразу - дорого... По этому поводу есть какие-нибудь мысли?