BanditosDima TТы уж извини, но я все-таки повозмущаюсь:
1. В конце селекта надо добавить NOFILTER иначе выборки не происходит
2. Выборку надо делать не из курсора, а из таблицы, и расшаренной. Обычно так открыты в рабочем софте.
3. SET DELETED ON (а не OFF, т.к. обычно у всех стоит ON) хотя на результат у меня это не повлияло.
4. Не вижу смысла дописывать в запросе AND DELETED() (тебе надо было т.к. у тебя SET DELETED OFF)
5. Одного раза мало, сделал запрос в цикле и WHERE ID=i для разнообразия.
Вобщем я его немного приблизил к реальности. И записей добавил, а то уж больно время маленькое получалось.

1. Вообще не понял. У меня работает во всех случаях. Вероятно, что-то я не знаю.
Работает, но выборки не происходит :)
В случае простых селектов фокс накладывает фильтр, примерно так:
проверить элементарно - посмотри что возвращает dbf('tmp')
Для замеров это принципиально, т.к. выборки всех записей не происходит, соответственно и время выполнения другое.

Banditos2. Хм. В ходе эксперимента специально был взят курсор, чтобы не было погрешностей работы с дисками. Потому что я физически не могу проконтролировать все процессы винды, которые будут писатть/читать на диск. А в работе с памятью это менее существенно.
Ну померил ты скорость проца и памяти. И чего? главный тормоза сетка и винт, даже в твоем случае как только курсор в кэш фокса не влезет - начнется своп и время увеличится на порядки, а своп начнется тем раньше, чем объем больше.
Banditos3. А вот это бред. Смысл тогда делать индекс по DELETED, чтобы потом его не использовать?
Индекс должен задействоваться автоматически при его наличии, согласно хэлпу:
HELPВместо этого, вы можете создать и использовать бинарный индекс, который оптимизирует бит, отвечающий за удаление записи, для увеличения производтельности, когда вы выдаете команду SET DELETED ON
Как я понимаю SET DELETED ON это автоматическое добавление "and deleted()" во все условия.
BanditosКстати, именно это показывает условие
которые Вы, почему то, выбросили.
Вероятно, потому, что именно это условие и показывало Вам, что Вы - не используете данный индекс. Вот Вы и выбросили его, негодного...
Я вообще никогда не смотрю чего SYS(3054) показывает, а выбросил чтобы он замеры не портил.
Когда меня интересует производительность - я меряю время.
Запускал пробовал оба варианта, с "and deleted()" немного медленнее . Код теста выше приведен, запусти так и так, выложи что получилось.
BanditosИ заблуждение про то, что типа

автоматически ВКЛЮЧАЕТ индекс DELETED - оставьте другим... Ибо это уже не смешно.
Кстати, вы еще с десяток индексов сделайте по другим полям, а потом выбирайте по ID - и снова удивляйтесь, как это индексы по другим полям Вам не помогают, а даже мешают! (не удержался, простите...)
ХЗ чего там тебе мешает, у меня так пишет:
SYS(3054, 2)SELECT * FROM mytable WHERE ID=10 INTO CURSOR tmp nofilter

Using index tag Mainid to rushmore optimize table mytable
Using index tag Del to rushmore optimize table mytable
Rushmore optimization level for table mytable: full

BanditosРегулярное обслуживание и ежедневная упаковка с переиндексацией - ДВЕ РАЗНЫЕ ВЕЩИ!!! И не нужно одно выдавать за другое.

И в чем же заключается это "Регулярное обслуживание" ?

BanditosЭто кому индекс должен задействоваться? С чего бы? А тот факт, что оптимизатор его не использует, как бы Вам не намекает, что индекс НЕ ЗАДЕЙСТВОВАН?
Я твой любимый SYS(3054,2) уже процитировал, еще раз то что у меня он пишет:
SYS(3054, 2)SELECT * FROM mytable WHERE ID=10 INTO CURSOR tmp nofilter

Using index tag Mainid to rushmore optimize table mytable
Using index tag Del to rushmore optimize table mytable
Rushmore optimization level for table mytable: full
Никаких "and deleted()" только SET DELETED ON

BanditosКстати, а откуда хелпик?
Тынц

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

BanditosЗЫ. Внимание: ищем разницу в "в упаковке и индексации" и в "ежедневной в упаковке и индексации". И думаем, думаем...
Запусти этот код, посмотри на результаты, и подумай чего может произойти пока ты соизволишь свое "регулярное обслуживание" провести:

BanditosDima T,
Вы издеваетесь?
Вы подменяете индексы и удивляетесь разному результату?
Я тебе показал что бывает при битом индексе. Подменять руками его не обязательно, достаточно того что комп на котором выполнится "UPDATE чего-нибудь" успеет записать изменение в DBF и не успеет в CDX (или наоборот), по любой причине: железо, сетка, пользователь задачу снял. Это редкость, но бывает, т.к. запись последовательно происходит, сначала один файл, затем второй.
И если это произойдет, то ближайшей переиндексации результаты запросов будут с ошибкой, если это будет долго продолжаться, то это приведет к тому что какой-нибудь пользователь это увидит и поправит согласно своим возможностям (т.е. усугубит проблему), и потом эти косяки надо будет кому-то разгребать.
Я этим "кем-то" был уже несколько раз. Поэтому предпочитаю минимизировать интервал с момента сбоя до исправления. У меня есть возможность индексировать базу каждый день, поэтому я ей пользуюсь.

BanditosSELECT * FROM mytable WHERE ID=10 INTO CURSOR tmp
Я уже писал что это не выборка, а поиск первой записи удовлетворяющей условию, т.е. равносильно команде

BanditosТак вот. Если создать тестовую среду без:
работает на 0.01 медленнее...
а если сделать PACK ?

Юристишко-выпускникя Вас просил остановиться только на таблицах
с наличием уд-х записей и проверить запрос:
SELECT Count(*) as cnt FROM mytable where id > 100 INTO CURSOR tmp nofilter

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

Результат в твою пользу, ускорение более чем в 100 раз, этому запросу очень нужен твой индекс:

Правда без индекса по ID твой хитрый индекс становится балластом:

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