Вместо решения "в лоб" через TOP 1 надо просто объединить таблицы и добавить исключение записей с датой, для которых существует бОльшая дата


Разумеется, это имеет смысл, если нет дублей по дате. Точнее, нет двух записей с максимальной датой.

Правда, не уверен, что такой запрос синтаксически корректен для VFP8.

АлексейОAleksey-KВсе зависит от наличия подходящих индексов. Например, по postn во всех таблицах и по dper в k2 да. эти индексы есть и 40 т. записей обрабатывает за 13-14 секунд, но этого мне мало.
Для отчета - вполне нормальное время. Пользователь воспримет такую задержку при выполнении отчета с пониманием и не будет "дергаться".

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

АлексейОно ... 4 секунды против 13-ти ... я выбрал scan.
SCAN-то зачем? Если стоит задача отображения в Grid, то можно использовать SET RELATION. Без дополнительного SET SKIP TO получится связь один-к-одному.

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

Итак, основная связь осуществляется по значению поля postn, но в пределах одного и того же значения поля postn надо упорядочить записи по убыванию значения поля dper. Т.е. первой должна быть запись с максимальным значением dper.

Если dper - это дата, то проще "перевести" ее в число. Поскольку разница двух перменных типа Date - это количество дней, то если вычесть dper из некоторой, заведомо большой даты, то и получим упорядочивание по убыванию. Затем переводим полученное число в строку.

Если поле postn типа Integer, то получаем такое выражение индекса


Теперь остается настроить связь


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

SET EXACT OFF

Но, поскольку это настройка по умолчанию, то проблем быть не должно.

Функция BINTOC() использована для уменьшения длины ключа. Для перевода в символьное представление можно использовать и STR(). Но, поскольку в данном случае, удалять ведущие пробелы нельзя, то ключ получится больше по размеру. А значит, бОльшего размера будет индексный файл.

АлексейОВладимирМSCAN-то зачем? :-)
ну это я образно сказал.
конечно именно так и сделано : индекс чтобы нужная запись была сверху, отношение во вторую таблицу, и даже не scan а replace all
Все-равно не понятно. Зачем выполнять модификацию? Разве факта настроенной связи недостаточно? Почему нельзя отобразить информацию напрямую из связанной таблицы без "перекачки" по REPLACE?

Если же нужна именно модификация, то почему нельзя наложить фильтр (не все же записи модифицируются), чтобы ограничить изменяемые записи и уйти от сканирования всей таблицы?

Собственно, что необходимо сделать-то? Какова решаемая задача, а не выбранный способ решения? Для чего изначально планировался запрос, описанный в начале темы? Что с этой выборкой потом происходило?

Ну, дело хозяйское.

Хотя должен заметить, что приложение, изначально написанное как файл-серверное, просто так перевести в клиент-серверное не получится. И термин "проще" здесь не уместен. Это принципиально другая идеология построения приложения.

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

Простой довод: в клиент-серверном приложении никто не будет тащить на клиента 40 тысяч записей. Это слишком долго.

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

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