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

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

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

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

men deaКоль LV без него не работает, как следует, то я ввел этот первичный ключ по неиспользуемому мною полю idmoney в таблице money.
Но вопрос: "Зачем все-таки он нужен в дочернем файле?" остался.
Если бы ты еще и объяснил, а что это за файл такой. Как в нем поддерживается актуальность данных. Как организованно поддержание ссылочной целостности.

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

men deaМне он представляется излишеством.
Это значит, что ты по прежнему не понимаешь назначение первичного ключа. Не применительно к Local View. А вообще. В любой таблице.

Цель первичного ключа - это однозначная идентификация записи. Т.е. по значению, записанном в поле первичного ключа всегда можно однозначно сказать, о какой именно записи идет речь.

men deaВ чем практическая польза уникальной нумерации каждой выплаты в money?
Еще раз. Не "нумерации", и идентификации . Это "две большие разницы"! Первичный ключ - это вовсе не обязательно число. Это может быть набор любых символов.

men deaНу, разве, что:
1. для вывода в порядке обратном вводу?
Ни в коем случае. Уникальный идентификатор записи служит только и исключительно для однозначной идентификации записи. Для целей сортировки вводи дополнительное поле.

men dea2. для синхронизации перемещения курсора в LV и соответствующей ему таблице или ее буфере?
Local View - это ОТДЕЛЬНАЯ (другая) таблица. Каким образом FoxPro должен определять, что вот эта запись Local View соответствует вот этой записи исходной таблицы? Т.е. как он должен идентифицировать записи? Только по значению ключевого поля.

Причем под термином "ключевое поле" применительно к Local View вовсе не обязательно следует понимать первичный ключ в исходной таблице. Это может быть и набор полей, однозначно идентифицирующих запись в пределах условия выборки конкретного Local View. Но практически, проще использовать первичный ключ исходной таблицы.

men dea3. или для унификации решения каких-то внутренних задач при реализации представления? Больше я ничего не придумал...

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