Sergey ChБыстрее всего REPLACE FOR

Нет. Это как раз самый неудачный (не скажу, что медленный) способ, поскольку в этом случае Fox пытается наложить табличную блокировку вне зависимости от реального количества изменяемых записей. А это не всегда возможно. Причем на эту команду распространяются ограничения накладываемые на команды с For-условием.

LOCATE FOR ... - надо уметь готовить. В смысле использовать. Новички обычно этого не умеют и получают страшные тормоза при включенном главном индексе. Это справедливо и для Replace for ...

Для новичков лучше использовать Update-SQL. Хотя тоже следует помнить, что эта команда игнорирует наложенные фильтры и могут быть проблемы с буферизированными данными.

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

StandD ВладимирМ
LOCATE FOR ... - надо уметь готовить. В смысле использовать. Новички обычно этого не умеют и получают страшные тормоза при включенном главном индексе. Это справедливо и для Replace for ...
Пожалуйста, если можно - поподробней. Нарывался и поэтому хотелось бы просечь...
Все ниже следующее относится к таблицам DBF при прямом доступе к ним из FoxPro.

Основа оптимизации (ускорения) в FoxPro - это индексы. Есть индексы - оптимизация возможна. Нет индексов - ну, тоже возможна, но уже очень специфическими способами и в очень ограниченном круге задач.

Если по тому выражению, которое указано в условии поиска существует индекс, то, по умолчанию, включается механизм, так называемой, rushmore-оптимизации. Что означает это слово - никто не знает. Просто звучит красиво и загадочно

Однако если выполняется команда с FOR-условием (LOCATE FOR, REPLACE FOR и т.п.), то на оптимизируемый поиск накладывается еще и главный индекс. Т.е. искать-то FoxPro ищет, но главный индекс заставляет искать в определенном порядке, чем сводит на нет все преимущество оптимизации.

Поэтому, для лучше оптимизации команд с FOR-условием, если это возможно по условию задачи, желательно отключать главный индекс.


Вот в этом случае rushmore-оптимизации ничто не мешает и поиск выполняется максимально быстро.

================
Однако если речь идет об удаленных данных (Remote View, Local View, CursorAdapter), то следует понимать, что результатом работы этих команд является таблица (курсор). Физически другая таблица. Выборка из исходных таблиц.

Поскольку это другая таблица, то, естесственно, она не имеет вообще никаких индексов. Поэтому говорить о rushmore-оптимизации для них - бессмысленно. Не может быть здесь никакой оптимизации. Вне зависимости от используемых команд. Разумеется, если Вы специально не создадите для них индексов. Но создание индексов занимает дополнительное время.

Однако по самой своей природе, выборка не должна быть очень уж большой. Это значит, что поиск в ней будет выполняться достаточно быстро и без оптимизации.

StandD
А вот еще вопрос. Старый правда, но интересно - про фильтр на гриде. Уже обсуждалась тема, все понятно, но можно ли ускорить "проявление" данных на гриде под фильтром отключая индекс? Вот это у меня не получается. Скорее всего, сделать нельзя, но вдруг? Полсто есть один кусок, нормально работающий, но вот с такой штукой. А переделывать все неохота.
Раз такой вопрос возник, значит про фильтр по прежнему не понятно.

Идея фильтра заключается в том, что это не есть нечто вычисленное один раз. Это условие, которые проверяется каждый раз при попытке перейти на очередную запись. Т.е. пытаешся перейти на запись и по новой вычисляешь фильтр. Поэтому факт наличия главного индекса существенно не влияет на скорость обработки фильтра.

Хотя, в VFP9 появилась специальная настройка


которая как раз и призвана подключить механизм rushmore-оптимизации к фильтру в Grid.

Однако присоединясь к совету Dima_T . По возможности, лучше отказаться от фильтра в пользу выборки, Local View или CursorAdapter. Дело тут вовсе не в быстродействии (хотя это тоже играет свою роль), а в способности приложения меняться под конкретную задачу (масштабировании приложения). Фильтр накладывает более жесткие ограничения. Их труднее расширить или как-то изменить под новые условия.