MdelТогда объясните, почему когда я ищу заведомо НЕСУЩЕСТВУЮЩИЕ данные, то есть вместо 43КМ549812 я ищу ОР99ГОШЛГН, то ответ о том, что таких данных нет приходит МОМЕНТАЛЬНО? с like без Like, по барабану.
Странно, попробуй поискать похожее на нормальное, но не существующее, что-то типа 43КМ439873
Mdel Galyamov Rinat
ускорения можно добится создав индекс по выражению right(field,6),

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

MdelЕсли хотите, я вам даже видео выложу как он моментом ищет левые данные и как долго существующие.. :) я прям в прострации :)
Видео не надо. Надо изначально корректно описывать задачу. Ясновидящих тут нет.
Было так:
MdelМне необходимо организовать поиск по последним 6 цифрам. Вот на это тебе и отвечали.

Давай рассмотрим как есть:
Mdelкороче, объясняю как есть :)
есть база ГАИ, в ней постановления о штрафах.
номер постановления 27ВВ155675 - точно есть(мой номер :) )
1. Индекс по полю есть.
2. Если я ищу прямое вхождение 27ВВ155675, то поиск по СЕТИ идет около 10-12 сек.
Полностью оптимизированный поиск по индексу + выборка результата по сети. Такая скорость тоже не устраивает?

MdelЕсли я ищу по like '27%155675', т.е 27% я добавляю в коде, а пользователь, чтобы не вводить буквы(для ускорения работы), вводит только цифры, то поиск идет около минуты.
Частично оптимизированный поиск. ищутся все записи начинающиеся на "27" и потом сравниваются на соответствие шаблону. Т.к. записей много (27 это регион или серия как я понимаю) и физически могут быть в разных концах DBF то это тормозить и без сетки будет.

Mdel3. если я ищу НЕСУЩЕСТВУЮЩИЕ данные, то есть по прямому вхождению ищу 27ВВ999999 - ответ что записей нет приходит моментом.
Полностью оптимизированный поиск по индексу, а т.к. в индексе нет, то выборки результата не происходит.

Некорректный тест. попробуй "27%999999" - думаю будет около минуты.

Что еще можно попробовать:
1. Шаблон заменить на '27??155675'. Хотя думаю это не сильно ускорит
2. Использовать монопольный доступ к таблице, тогда издержек на блокировки не будет и клиент кэшировать будет. Как вариант иметь обновляемую копию на клиенте, возможно только поля с номером и Id записи, тут индексы какие угодно можешь создать, делать выборки списка Id, а по Id запрос к основной базе.

Mdel... Вопрос в том, почему поиск идет так долго? Если открыть таблицу в Visual FoxPro (shared) через сеть и выполнить запрос то результат придет мгновенно. Неужели проблема скорости в VFP OLE DB ?
Может на фоксе написать? C# по какой причине выбран?

Mdel Dima TМожет на фоксе написать? C# по какой причине выбран?
По той простой, что на фоксе я не писал уже года 3-4, а в C# пишу постоянно :)
Еще подумай о фоксе, тем более писал раньше.

MdelНа поле постановления было 2 индекса: 1-по всему полю, второй вида SUBSTR(postanov,5,8) - то есть поиск по номеру постановления без 27ВВ. То есть я теперь утверждаю, что индексы используются, хотя ВладимирМ упорно не хочет это признать :)
ВладимирМ вероятно не ознакомился со всеми твоими тестами.
MdelВот здесь я описал в чем проблема такого длительного поиска.
Там ответили, я тоже по твоим тестам на 90% уверен что дело в OLE DB. Так-что выбирай или тормоз с OLE DB, или COM для запросов на фоксе или целиком на фоксе писать.

Как вариант попробуй по OLE DB из фокса. Если тоже 10-12 сек., то это не в пользу OLE DB