FoxPro не создает индексы с перменной длиной ключа. Просто не может. Ни в какой версии.

Вы создали условие объединения именно по переменной длине ключа. Каким образом следует сопоставлять подобные выражения? Возможны два варианта:

1. Отсекаем/дополняем выражения до некоторой фиксированной длины, строим временный индекс по этой фиксированной длине и сравниваем значения ключей
2. Никаких индексов не строим и сравниваем ключи "как есть"

Естесственно, в первом случае мы рискуем получить не вполне корректные данные за счет того, что выражение ключа временной индекса не соответствует реальным сравниваемым значениям.

Ну, например, простейший вопрос: а до какой длины надо дополнить или отсечь значение ключа? Скорее всего, по значению первой попавшейся записи, иначе прежде, чем создать индекс придется просканировать обе таблицы на предмет максимальной длины полученного выражения. И если выражение в первой попавшейся записи окажется, скажем, длиной 3 символа, то не понятно, что Вы вообще получите в результирующей выборке!

Если бы Вы использовали функцию SYS(3054), то увидели бы, что при фиксированном значение длины полученного выражения строится временный индекс, а при переменном, объединение выполняется по принципу "Cartesian products", т.е. "тупое" сканирование всех записей, что дает необходимость просканировать 1000*1000 = 1 000 000 записей. Что без индекса выполняется ОЧЕНЬ медленно.

Другими словами VFP9 поступил абсолютно правильно, не став создавать временный индекс. Ну, а тот факт, что при этом время выполнения подобного запроса увеличилось на порядки, должно было Вам подсказать, что само условие объединения не корректно.

В ранних версиях FoxPro (VFP7) результат подобной выборки будет сомнителен. Неизвестно ведь, какое выражение ключа окажется у временного индекса. В смысле, сколько символов.

Питон33ВладимирМ,

Для быстрого поиска важно чтобы было оптимизированное выражение для рашмора.Выражение будет Оптимизировано если левая часть от оператора "=" будет такая как при создании индекса, а правая пофиг.
Вот тогда будет летать.
Ну, для начала, в SQL-запросах не имеет значения "справа" или "слева" стоит выражение. Вы путаете SET ANSI и SET EXACT. Они похожи, но отличие как раз в том и заключается, что для SET EXACT важно положение "справа" или "слева", а для SET ANSI - нет. Кроме того, наличие индекса по обоим выражениям все-таки имеет значение. Другой вопрос, какой из них будет использоваться и будет ли использоваться вообще, зависит от конкретного запроса.

И еще, Вы собственно вопрос автора темы читали? Какое отношение это все имеет к заданному автором темы вопросу?

В данном случае индекса нет вообще. FoxPro создает временный индекс. Но! По использованному выражению в условиях объединения построить корректное выражение ключа для временного индекса нельзя (точнее, быстро нельзя). Как следствие, VFP9 и не пытается. Отсюда - тормоза. Ранние версии FoxPro строят-таки временный индекс, но не факт, что значение его ключа будет корректно. Как следствие, не факт, что результат выборки будет корректным.

Питон33И потом я не люблю все эти Джойны, не проще ли юзать фразу WHERE?
Нет. Не проще.

Во-первых, объединение двух таблиц (Join) и фильтрация записей одной таблицы (Where) - это все-таки разные процессы. И первое, что делает анализатор запроса это как раз и пытается отделить одно от другого. То, что Вам кажется "одинаковым" на самом деле таковым не является. SYS(3054,11) - это четко показывает

Во-вторых, реализовать внешнее объединение (Left, Right, Full) только через Where - невозможно в принципе. Придется делать объединение по UNION.

Питон33Иногда два последовательных селекта подряд работают быстрее одного закрученного в бараний рог.
Да. Конечно. Только ключевое слово здесь "иногда". А, кроме того, опять же, какое это имеет отношение к данному запросу? Вполне себе примитивному, если не считать совершенно бессмысленного усложнения условия объединения?

Питон33ВладимирМНу, для начала, в SQL-запросах не имеет значения "справа" или "слева" стоит выражение. Вы путаете SET ANSI и SET EXACT.
В SQL запросе ВСЁ имеет значение.
Чтобы запрос был оптимизирован механизмом Rushmore, юзер обязан слева от знака "=" написать Поле базы, а справа Выражение.
ВладимирМ, начните изучение Foxpro с версии 2.5, тогда у вас в голове наконец появится ясное представление об оптимизации Rushmore.
Чтобы проверить - достаточно создать таблицу из миллиона записей и проиндексировать её по текстовому полю.
ВладимирМ, не забывайте про Rushmore даже когда вы спите! :))
Долго же Вы собирались с ответом, чтобы просто поиграть словами Почти месяц. При этом так и не удосужившись прочитать исходный вопрос автора темы.

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

Питон33Ответ был по делу и поможет в 100% случаев решить проблему.
Какую проблему-то? Вопрос автора темы звучит так: Есть запрос. В VFP7 он оптимизируется, в VFP9 - нет. Почему?

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

PS: Если Вы до сих пор не поняли, что такое JOIN и как его использовать, то это Ваша беда. И тут вовсе нечем хвалится.

PaulWist,

Ну, так он это и показал уже. Идея заключается в том, что сначала создается специфический курсор-диспетчер, который имеет всего одно поле - ключ. Это поле формируется просто объединением по UNION ключей обоих таблиц. При этом дубли исключаются.

Затем по SET RELATION этот курсор-диспетчер связывается с исходными таблицами. Собственно, все.

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

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

Питон33А на счёт SET RELATION после Джопов - это вопрос не ко мне а к тому кто рисует Джопы.
Те, кто использует Join, как правило вообще не используют SET RELATION.

Питон33В прикладных бухгалтерских и складских задачах проще и понятней делать через SET RELATION.
Время надо ценить.
Лично я считаю наоборот. Одна команда Select-SQL наглядно показывает все взаимосвязи таблиц и никак не влиет на другие рабочие области.

Использование SET RELATION - это всегда настройка среды в нескольких местах и при этом надо учитывать возможное влияние подобной настройки на другие модули приложения. С точки зрения отладки, SET RELATION значительно усложняет процесс и Вы теряете время.