Ну и топик получается... Малоконструктивный. Так сразу и не разберешься. Попробуем по одному. Надеюсь, Эксель в повседневной жизни все видели ;-)? Буду проводить аналогии с его интерфейсом.

brahew - знает плюсы FS, сейчас внедряет CS. Согласен, что выборку в CS желательно делать поуже, и не стесняется это сказать.
Фраза "тетка говорит, Рома почему я не могу просмотреть ВЕСЬ(!!!!!!) справочник улиц в задаче абонентского?Это так надо!" многих ввела в заблуждение, но это понятно, с точки зрения тетки именно так все и происходит: как будто мгновенно появляется весь справочник. Потому что она, как в Экселе, может нажать PgDn - и тут же увидеть следующую страничку. Может подергать за бегунок линейки прокрутки - и тут же оказаться в прогнозируемом месте. Может и поиском пользоваться. Кстати, поиск простым пользователям понятнее выборки ;-).

Ermak - Не читал первый пост - там я говорил о незащищенности как о первой проблеме. Задал 2 вполне резонных вопроса.
1. В чем разница между FS и CS технологиями, если в обеих все начинается с поиска?
Поиск в случае FS означает поиск как в Экселевской таблице, в другом подразумевает запрос к базе и получение выборки (ее тоже можно оформить как в Экселе, но при ошибке в наборе искомого в первом случае можно перелистать до его нахождения, а во втором придется набивать искомое заново - впрочем, зависит от реализации, может, придется только букву поменять).
2. Почему в Вашей реализации CS не видно ни цены, ни остатков???
Потому что это EBS. На самом деле, их видно, потом. Для выбранного препарата. Кто знает, скорее подтвердит, чем опровергнет: сообществом внедрятелей EBS любая чрезмерная его настройка под нужды конкретного пользователя считается злом (слова не мои, проходили в форуме по Oracle, автора не помню, но ему не возражали). Сложные стандартные формы вообще не берутся переписывать (и правильно делают, поскольку EBS все время развивается, патчи ставить - бытовое дело). Впрочем, сказанное не значит, что настроить в принципе нельзя. Только учти, что цену придется добавлять ценой трех табличек, с range scan, а на текущие остатки влияет состояние еще трех табличек, с групповыми функциями в каждой. Тормозить не будет? Да, учти, изменять структуру данных вообще запрещено!

alex_k - придерживается нейтралитета. Знает недостатки CS, но не собирается делиться опытом, как с ними бороться. Поклонник firebird. Цитата: "только надо _программу писать_ а не собирать из кубиков на форме". Вероятно, введен в заблуждение словами "стандартная функциональность".

Веревкин - скорее, настроен благодушно. Ленив ;-) Первый из оппонентов, который что-то предложил. Знает EBS, судя по фразам "Форму только надо свою рисовать" и "custom.pll можно обойтись". Узнал во мне какого-то своего знакомого. Отвечу: там, где я работаю, трамваи не ходят. Попрошу далее не отклоняться от темы.
По поводу предложенного решения. Ты хочешь сказать, что сначала мы выгружаем все данные, а потом при перепозиционировании курсора обновляем поля, вероятность изменения которых высока, в той записи, куда приходит курсор? Почти то самое, но не совсем. Вот если бы был триггер на запись, которой до этого не было на экране, а потом появилась ;-)... А так - сначала данные будут хорошо соответствовать, а потом все хуже и хуже. А почему, собственно, я (читай: пользователь) должен мириться с тем, что цена и остаток видны только по той записи, на которой стоит курсор? Движения глаз быстрее движений рук, и если запись об интересующем меня товаре уже на экране, зачем мне еще переводить на нее курсор? (Черт подери!)

viman - по начальным постам складывается впечатление, что человек совсем не знаком с FS, хотя пишет, что работал. Потом появляются проблески узнавания ;-) Въедливый. Придирается к словам (и правильно делает, пожалуй, без его участия мне бы не пришло в голову заглаживать некоторые корявости в своих предыдущих постах ;-)) Работает с IB и Oracle. Любит цифры. Особенно тысячи. (Хочется закончить: особенно долларов, но повода нет ;-)). Интересный собеседник, хотя любит уклоняться от темы. Приводит контрзадачи. Надо бы разобрать предложенный им пример, да лень. Скажу только, что в его примере реализация FS была явно неудачная. Гораздо бОльшие объемы данных перерабатывались моими отчетами в FS на порядок быстрее. Правда, для ускорения выполнения больших аналитических отчетов на FS есть своя специфика. В частности, не нужно стараться слепить один большой запрос. Лучше разбивать на несколько маленьких запросов, попутно забирая выборки на клиента, на клиенте индексировать по ключевым полям и уже здесь строить окончательный отчет.
Предложил как панацею вложенный селект. С учетом ответа на вопрос Ермака №2 и условий поставленной в моем посте от 03:24 15 октября, отвечу. Усложнение селекта приведет к увеличению времени на его выполнение. Да хоть (select sysdate from dual) вложи в другой запрос - и такая малость (пусть 1 миллисекунда на запрос) с учетом того, что общее количество запросов в течение дня составляет (см. предложенную задачу) уж никак не меньше физического минимума 1000 (заказов) * 20 (строк в заказе в среднем) = 20000, а фактически намного больше (заметьте, случай, когда менеджера спрашивают "А что у вас вообще есть" - вообще предпочитают не рассматривать) - и то отъест у сервера 20 лишних секунд!
Кстати, уж коли ты помянул события, есть еще одно избитое словосочетание: "событийно-управляемый интерфейс". Покажите мне хоть один не событийно-управляемый интерфейс! (Пакетная обработка не считается, у нее вообще интерфейса нет, кроме параметров ;-)).

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

Серега - краток, метафоричен и во многом прав. В первом посте. Потом Остапа понесло ;-).
Взять хотя бы утверждение, что по сети все происходит медленно. Может, у Сереги плохая сеть?
Далее, по-твоему что получается, если сделать FOPEN и FSEEK в конец файла - файл при этом будет прочитан от начала до конца в память? И еще, цитата: "А как ты например обеспечишь права доступа, когда конкретному юзеру из этих 600 000 записей читать можно только 600 (остальные не его)? Правильно, скачаешь ВСЕ и отфильтруешь." На самом деле так неправильно. В этом случае я подумаю об SQL SELECT или SET KEY (а никак не о SET FILTER).
Впрочем, это тоже проблемы незащищенности.

q - интересуется: а что означает файл сервер (в этом топике)? файл сервер типа ENCINA? или может просто файловая система? Отвечаю: ENCINA не знаю, речь идет о базах данных, доступ к таблицам которых осуществляется как к файлам, расположенным на файл-сервере. Т.е. приложение СУБД, запущенное на клиенте, читает файлы базы данных и пишет в них само, а не передает запросы серверу. Задача сервера при этом - иметь быстрый дисковый массив, быстрый сетевой канал и ОС, заточенную на обслуживание обращений к файлам, расположенным на сервере. Логику работы с данными реализует клиентская часть.

tygra - краток и категоричен. В FS не въезжает. Одно из двух: или не любит пользователей, или давно познал истину. Не завидует моим заказчикам. Ошибается, заказчики меня любят ;-). Особенно девушки ;-).

U-gene & tygra - докажите, что с сервера можно часто забирать много информации, и я вам все прощу ;-) (только ДЕЙСТВИТЕЛЬНО часто и ДЕЙСТВИТЕЛЬНО много). Я о том, что даже если все оптимизировать донельзя, предел обслуживания с увеличением нагрузки рано или поздно наступит.

eNose - Веселый человек. Знает тайну черепахи Тортиллы напару с viman, но не делятся (я про компоненты Query и Table не знаю).

Crip - ну, этот свой ;-) Намекнул на какие-то вещи и ушел. Абыдна! Вернись, расскажи подробнее!

andrew_Pr - THE BEST! ;-))))) Но пользователей все равно надо любить!

Пока побеждает Веревкин. Но решение нельзя назвать вполне удовлетворительным...