w3d PaulWistЧто бы определить уровень оптимизации включи SYS(3054,11) - эта ф-ия покажет какие индексы используются для поиска, желательно добиться слова FULL, отсюда танцуй добиваясь оптимизации запроса

А как его включить?
У меня на форму текст какой-то выводится...
Это выводится результат работы функции SYS(3054). Можно перенаправить его в текстовый файл.


Потом смотрим текстовый файл MyLog.txt.

Хотя в версии VFP9 можно уже явно указать в функции SYS(3054) куда выводить результат анализа.

Urri
1. index on alltrim(sh) tag alsh - в корне неверно!

Не совсем. Такой индекс эквивалентен отбрасыванию ведущих пробелов.

Т.е. конструкция допустима, но FoxPro сам, автоматически, после отсечения ведущих и концевых пробелов добавит концевые пробелы в выражение ключа до количества символов в поле sh.

Идеологически, да, неверно. Но в описанной ситуации вполне уместен. Дело в том, что замена на "простой" индекс по полю sh означает серьезную переделку всей программы. Если стоит задача поставить "заплатку", то сойдет и так.

Urri
2. index on alltrim(sh) tag alsh - не поможет, так как == не оптимизируется.

Оптимизируется. Не надо забывать, что сравнение символьных строк в "обычных" командах FoxPro и внутри команды Select-SQL работает немного по разному.

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

Т.е. это "локальное" применение настройки SET ANSI ON. На факт оптимизиации никак не влияет.

PaulWist ВладимирМНе совсем. Такой индекс эквивалентен отбрасыванию ведущих пробелов.

Т.е. конструкция допустима, но FoxPro сам, автоматически, после отсечения ведущих и концевых пробелов добавит концевые пробелы в выражение ключа до количества символов в поле sh.

Идеологически, да, неверно .

Господа, маленькое замечание по поводу ALLTRIM() в индексе, все рассуждения строятся на том основании, что данные будут заносится и использоваться исключительно в Ваших программах, НО ни кто не рассматривает того варианта, что другой софт, стороннего разработчика может общаться с Вашими данными, и о том, что "я всегда убираю начальные пробелы" этот софт может и не знать, поэтому ALLTRIM() является общим решением для индекса, а LEFT, PADR - это частные решения для Вашей задачи.
Маленькое замечание по замечанию.

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

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

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

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

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