Для выполнения поиска по первым символам ключа необходима настройка


Вообще-то, это настройка по умолчанию, но у тебя она видимо изменена.

MFoxer olegovда блин, используй ты locate про скорость выборки врут, на нынешних компах примерно та же что и у seek
А Вы собственно знаете разницу между алгоритмами перебора и алгоритмами половинного деления ? И наверное итерационные задачи решали, да ? Даже не смешно, честное слово.. пионерское.
Для справки.

В FoxPro оптимизируются ВСЕ команды и функции, имеющие FOR-условие. В том числе и LOCATE. Это значит, что в случае наличия простых индексов по полям "Фамилия", "Имя" и "Отчество" конструкция вида

SELECT MyTab
SET ORDER TO 0
LOCATE FOR "Фамилия" = ... AND "Имя" = ...

Также будет оптимизирована и скорость поиска будет сопоставима со скоростью поиска по SEEK(). Разумеется, меньше, но не так уж чтобы очень...

MFoxerВладимирМ, не будет. Давайте проведем эксперимент. Только определимся с алгоритмом и конфиргурацией компьютера и структурой и объемом данных.
Оптимизация движка фокса и алгорим просмотра записи 2 разные вещи, IMHO.
Давайте сначала определимся с терминами.

Задача: найти одну запись.

Какое отношение к этой задаче имеет "оптимизация движка фокса" и "алгоритм просмотра записи"?

В FoxPro есть так называемая Rushmore-оптимизация. Это механизм ускоренного поиска данных основанный на использовании индексов. Так вот, в HELP по FoxPro так и написано:

HELP VFP9Use Rushmore to optimize data access according to the number of tables involved. When you access single tables, you can take advantage of Rushmore anywhere that a FOR clause appears. When you access multiple tables, SELECT - SQL queries supersede all Rushmore optimizations. In an SQL command, Visual FoxPro decides what is needed to optimize a query and does the work for you. You don't need to open tables or indexes. If SQL decides it needs indexes, it creates temporary indexes for its own use.

Или, то же самое из переведенного HELP к VFP3

HELP VFP3При обработке одиночных таблиц преимущества технологии Rushmore сказываются везде, где используется предложение FOR . При обработке многотабличных запросов команда SELECT - SQL перекрывает все обычные правила, требуемые для технологии Rushmore. Команды SQL автоматически определяют необходимые правила оптимизации запроса. Вам не надо самостоятельно открывать таблицы или индексы. Если для выполнения запроса SQL потребуется индекс, он будет создан на время выполнения запроса.

Далее идет список потенциально оптимизируемых выражений. Среди них и команда LOCATE.

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

SET ORDER TO 0

на которое мало кто обращает внимание. Если установлен главный индекс, то да, действительно, будут большие тормоза. Но если его отключить, то скорость поиска будет сопоставима с SEEK(). Повторюсь. Все-таки медленнее, но речь уже будет идти не о порядках, а о "разах".

MFoxer>Какое отношение к этой задаче имеет "оптимизация движка фокса" и "алгоритм просмотра записи"?
Элементарное. Движок работает на уровне оптимизации страниц(4 КБ), а SEEK как и Locate использует алгоритмы и ему начехать, как там внутри. А Вы мне установки "тычете" . Рашмор - да, круто. Да Эффективно. А как сделан этот самый Рашмор Вы хоть раз задумывались ?
У нас стоит задача проверить эффективность работы (скорость поиска) или узнать "как оно внутри тикает"?

Как "этот самый Рашмор" работает я примерно представляю, а вот как он сделан - понятия не имею. И по прежнему не вижу, как именно "оптимизация страниц (4КБ)" может повлиять на скорость поиска нужной записи.

Знаете, я уже на практике убедился, что оптимизация (ускорение) LOCATE работает . Если у Вас есть возражения - приведите пример.

MFoxerВладимирМ, оптимизация ( ускорение ) LOCATE , по сравнению с чем ?
Вы помните, с чего лично Вы вообще ввязались в эту дискуссию?

olegovДа блин, используй ты locate про скорость выборки врут, на нынешних компах примерно та же что и у seek

Да, если индексов нет, то команда LOCATE будет вынуждена сканировать записи таблицы, что само по себе медленно. Поэтому с самого начала, когда я вступил в дискуссию, я Вам напомнил, что команда LOCATE может быть оптимизирована (ускорена).

Насколько я понимаю, Вы слишком увлеклись опровержением высказывания olegov и просто не поняли, что я Вам напомнил, причем подчеркнул как "К сведению".

А напомнил я Вам очевидный факт. Команда LOCATE может выполняться медленно или быстро в зависимости от того, будет ли ее выражение оптимизировано.