leafЯ бы на вашем месте выбрал всё в курсор и присоеденил к гриду
А как тогда редактировать данные?
Вообще-то, пробовали уже через View, но пользователей не устраивает время открытия формы - с Viewшкой открывается больше минут :(

Alex Sheffоднозначно при таком количестке записей нужно пользоваться SELECT INTO CURSOR - будет гораздо быстрее
Это вместо фильтра ? или вообще?

Спасибо! Попробую.
Но проблема все-таки не столько в скорости, сколько , как мне кажется, стандартный грид не в состоянии нормально показать таблицу после фильтра.
Трудно это объяснить "на пальцах". Но когда фильтры ставишь в оболочке Фокса никаких проблем нет. Когда на форме в гриде - виснет при переходе по записям. Особенно если скроллинг грида покрутить.

AleksMedМожно WHERE, но думаю что через VIEW половчее будет работать, все равно когда никогда с этим придется разбираться.
Это вы просто не пробовали представление с таблицы в 600тыс записей создавать. Даже просто View открыть около 2х минут.
Это нервы надо железные иметь, чтоб дождаться открытия формы с таким view.

leaf А как тогда редактировать данные?
select ... into cursor readwrite
в другую форму а при закрытии анализ сделанных изменений
кстати редактировать данные напрямую не есть хорошо
Таблица буферизована, так что можно откатить изменения, сохранить если все нормально и все такое. А фильтр используется для массовых изменений, да и просто оператору удобно - видит только информацию по выбранным условиям.

e AleksMedВсе конечно зависит от объема и структуры данных.
И такой большой базы под рукой нет.Создал базейку из двух полей, залил 120000 записей, создал параметризированное VIEW, время открытия 3,295 сек.
Это точно! Но у меня - 24 поля(от 7 до 60 симв) и 600тыс записей (каждый день прибавляется 500-600 записей , монстр , однако :)), и никак не меньше 1.5 минут представление открывается.

AleksMedИ что все 600000 заливаешь во VIEW?
Не все. 150 тыс, может чуть больше.
Это имеет значение?

Спасибо всем за советы!
Обошлось все буквально парой строк - замена установки фильтра на создание вьюшки, ну и заменой рекордсурса грида в форме на эту вьюшку.
Но, все-таки, что-то не то с гридом.

Igor KorolyovТы в упор не прислушиваешься к вопросу ЗАЧЕМ пользователю 150000 записей!Сделай ему удобную форму задания параметров, продумай ЧТО он обычно ищет и КАК - сократи объём выборки до 100 ну максимум до 1000 записей (ессно используя параметризованный View). Потом добавь индексы по полям, входящим в условия отбора (отбираем по дате - делай индекс по дате, отбираем по какому-то коду, возможно связанному с другой таблицей - делай индекс по коду). И будет тебе счастье, будет заполнятся курсор за < 1 секунду! И все будут просто счастливы!
А Grid+Filter и Grid+Relation медленная и мучительная смерть :(
Вообще-то, пользователь хочет видеть все 650тыс записей, и по ним делать выборки , которые можно редактировать, но поскольку такие проблемы с гридом и фильтром, была идея поделить информацию по годам , что ли . Отсюда и 150тыс записей. Но это была плохая идея.
Пока пробую выборки делать во View, и менять датасурс грида с самой таблицы на local view.
Идеально было бы воспользоваться советом acrisuin'a , насчет set key . Индекс для выборки создать можно, а вот как использовать Set key range для выборки с разными типами полей непонятно. Точнее в текстовом виде некорректно как-то обрабатываются поля с датами.
Или , если index по полям dtoc(data1) + region , то
set key range '01.04.2004'+'Советский', '01.05.2004'+'Советский'
выбирает информацию за 01.04.2004,01.05.2001, 01.05.2002,01.05.2003,01.05.2004 и не обращает никакого внимания на значение поля region. Или я что-то неправильно делаю??

2AleksMed
Нельзя, потому что это будет уже совсем другая форма :)
Собственно, задача стоит продержаться до появления новой программы.
Поэтому,радикально переделывать процесс, и переучивать пользователей не хочется.
Сейчас нужно : показать пользователю все записи что у него есть.
А пользователь затем либо просматривает\редактирует(с возможностью отката изменений), либо делает выборку, просматривает ее и потом редактирует ее (раньше использовался фильтр), либо делает выборку для отчета(просто курсор).
А сразу заставлять выбирать условие нам не подходит. Может пользователь просто полистать информацию за год-два хочет, а представление с нашей информации только открываться пару минут будет.

2Трехсотый
Дело не в периоде. Просто открыть форму , посмотреть и поредактировать - нет проблем, ни со временем открытия, ни с чем либо другим. 4 года так работают, и вполне довольны :) Проблема в гриде. При больших объемах данных он не в состоянии показать нормально отфильтрованные данные(выборка делается по значениям от 1го до 6 полей таблицы, одно из которых - дата).Вот и приходится выкручиваться :)
Может кто подскажет, как все-таки пользоваться set key range , если индекс по нескольким полям. Лучше с примером.

2ВладимирМ
Спасибо за подсказку dtos() :)
Но как все-таки написать set key to range правильно, если индекс по dtos(time)+left(region).
Устанавливать
set key to range '20040101'+'Советский','20040131'+'Cоветский'
по дате нормально, а на район - ноль внимания.
Как правильно?

Трехсотый
Грид при небольших частях данных будет открываться моментально и отображать как надо.
Или я опять не правильно понял проблему и все дело в сортировках внутри грида???
2Трехсотый:
Проблема в том что надо выборку редактировать. С фильтрами все виснет, а представления открываются долго, а отдельно потом изменения закачивать в основную таблицу муторно.

Urri... То получим совсем не то, что хочется.
Bege хочет по одному району за период. А получается - за период, но районы игнорируются (нельзя сказать, конечно, что совсем игнорируются, но поведение странное). И почему же, интересно? ;-)
А если вспомним про сортировку строк? ;-)))
Что, запись '20040101'+'Турецкий' не попадет в set key to range '20040101'+'Советский','20040131'+'Cоветский' ??? ;-)))))))))
2Urri : Вы правы, при такой сортировке все районы попадают в выборку.
Конечно же правильнее (спасибо acrisiun!), наоборот, region+dtos(time) .
Но полей для выборки шесть, и получается что надо либо создавать индекс каждый раз по выбранным полям (условиям выборки), что невозможно, потому что таблица буферизованная , да и по времени создание индекса не устраивает. Или насоздавать индексов заранее , сколько там получится комбинация из 6ти ? :) Тоже вопрос.
2 XAndy: Нормализация нужна, не спорю, даже по 4 полям можно. Не знаю о чем думали разработчики этой программы, возможно были и у них какие-то резоны. Сейчас просто нет смысла глобально переделывать это приложение, в ближайшее время начнем разработку замены. А пока поддерживаю в рабочем состоянии эту программу.
ВладимирММне кажется, Вы чего-то не понимаете:
-) Либо пользователь ждет один раз пока откроется Local View, либо он наблюдает постоянные тормоза при перемещении по записям.

2ВладимирМ : Пользователь заходя в форму для редактирования данных может делать сколько угодно выборок. Им так удобно : выбрал какие-то записи - отредактировал, чтоб другие записи даже и не видно было.
Индексы есть, и насчет ускорить выборку индексированием я уже написала выше. Видимо, я немного туманно обрисовала проблему сначала, но сейчас-то уже все честно рассказала. Могу эту формочку вывесить, если кому интересно .

Файл с формой