bushuyevНе пинайте за синтаксис, подскажите, где накосячил...
Есть две DBF таблицы одинаковой структуры. Цель, сопоставить по определенным полям записи...
Вообще ни одной не находит...

А должны? В смысле, точно известно, что есть такие?

Кстати, для размышления, как Вы думаете, будут ли различаться такие строки

"1" + "11" и "11" + "1"

Это по поводу того, как именно Вы строите выражение для сравнения.

Попробуйте более простые решения, например, LOCATE


Хотя, разумеется, еще проще было бы сделать это при помощи Select-SQL.

12345вышелзайчикпогулять авторПопробуйте более простые решения, например, LOCATE
да, и на порядок медленное

При наличии тех индексов, которые Вы рекомендуете строить (по каждому полю в отдельности) скорость поиска по LOCATE будет сопоставима со скоростью поиска по SEEK(), поскольку команда LOCATE также использует Rushmore-оптимизацию. Однако в отличие от SEEK может одновременно использовать несколько индексов.

12345вышелзайчикпогулятьконечно, индекс, строим с разделителями позиций
В общем случае, такого лучше не советовать по ряду причин.

1. Одно из полей внутри себя может содержать использованный символ-разделитель.
2. Время построения такого индекса "съест" весь выигрыш от производительности при его использовании. И еще не факт, что поиск вместе с построением индекса окажется быстрее, чем поиск без использования индекса вообще

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

Гораздо выгоднее (во всех смыслах) создать несколько "простых" индексов, чем один составной.

12345вышелзайчикпогулятьпопробуйте команду СКЛ языка Select
INNER JOIN в данном случае использовать не корректно, поскольку из условия задачи не ясно, будут ли совпадения в единственном числе. Поэтому надо использовать IN или EXISTS()


12345вышелзайчикпогулять+ доп.бинарные по dele() (при set dele off)
Необходимость использования индекса по Deleted() - вопрос спорный и не однозначный. В подобных задачах эту тему лучше не поднимать.

bushuyevВообще ни одной не находит...
SELECT 1
USE i
INDEX on CHRTRAN(...,' ', '') TO i_nd

А не находит он именно из-за использования ChrTran().

Дело в том, что в среде FoxPro все индексы имеют фиксированную длину ключа. Это значит, что, если выражение индекса для первой записи сформирует длину ключа, скажем в 10 символов, то и для всех остальных ключей длина также окажется равной 10 символам. Даже если выражение вернет больше символов. "Лишние" символы будут просто отброшены.

Как правило, FoxPro сам, автоматически, дополняет длину выражения до некоторой фиксированной длины при использовании простых функций. Например, если выражение ключа написать так:

AllTrim(Field1)

то FoxPro, конечно, отбросит ведущие и концевые пробелы, но затем сам, автоматически, добавит концевые пробелы до длины поля Field1.

Однако в сложных функциях вроде ChrTran() такого автоматического дополнения не происходит. В этом случае надо озаботиться ручным добавлением пробелов до некоторой фиксированной длины, например, с использованием функции PADR()


Кстати, если Вы используете ChrTran(), то нет смысла использовать AllTrim(). И наоборот. В данном случае - одна из этих функций делает то же самое, что и другая. Разумеется, если не может оказаться пробела внутри значения поля. Вы просто дублируете одну и ту же операцию.

Dima TА дальше можно по SET RELATION связать и за один SCAN обработать.
Если настроен RELATION, то проверять надо на EOF() подчиненной таблицы. Ведь если значения нет, то мы просто попадем на фиктивную запись подчиненной таблицы. А проверять на EMPTY() - некорректно, ведь запись действительно может быть пустой.