Иногда возникает необходимость отображать содержимое связанных по "SET RELATION TO ..." free-файлов не через Grid, а через Controll'ы, отображающие содержимое полей только ОДНОЙ (текущей) записи. При этом весьма удобно, если пользователь видит в одном из Controll'ов формы текущую позицию (в дочернем файле) в виде "n/k", где k - количество дочерних записей, соответствующих текущему значению связующего индекса главного dbf-файла, а n - порядковый номер ОЧЕРЕДНОЙ из этих "соответствующих" записей. Я обычно для этого "насильно" добавляю в каждый дочерний файл числовые поля N и K, значения которых перевычисляю каждый раз в методе INIT() запускаемой формы. Значения этих полей соответственно корректируются при вставке и удалении записей. Сами эти поля я связываю со свойствами ControlSource соответствующих "индикаторных" Controll'ов формы.
Но, дело в том, что я и сам нахожу этот метод отслеживания текущей позиции в дочерних файлах несколько неуклюжим. Можно было бы попытаться обеспечить это полностью арифметическими методами отслеживания текущей позиции (без привлечения вспомогательных полей N и K), но при этом трудно обеспечить соответствие отображаемых значений при добавлении и удалении записей, а тем более - при непредвиденных сбоях в работе системы, не говоря уже о случаях с БОЛЬШИМ количеством записей в отображаемых файлах.
Может, кто-нибудь сталкивался с подобной проблемой? Как вы ее решаете? Подкиньте идейку, плиз :)

Вот прилагаю пример в архиве. Разархивировать надо в C:\111\, чтобы рисунки на кнопках отображались (издержка демо, простите). То, о чем я спрашиваю, отображается в оранжевых TextBox'ах.

To Redrik:
Да будет вам! Сказано же - это только вырезка для демонстрации, и не более того. Поля, их форматы и содержимое сформированы только для примера. Я здесь на форуме уже приводил под членским ником свои функции преобразования кода в дату рождения, так что - плавали, знаем :)) И изобличение пола по коду там тоже обсуждалось. Ваш ответ, действительно не в тему.
А если не козырять НЕтематической осведомленностью, то ответ требуется примерно следующий:
нужна идея для более "уклюжего" механизма отслеживания и отображения текущего положения в дочерней таблице, чем через ее вспомогательные поля N и K. В контейнере баз данных это можно было бы возложить на хранимые процедуры, но в данном случае речь идет именно о свободных таблицах.

Да я и сам понимаю, что универсальности тут быть не может. Тем более, представлениями не оперировал - как-то не сложилось у меня с контейнерами БД, предпочитаю free-tables. Видать, меня dbc-шками в детстве сильно напугали :))
А вот насчет частных выборок для уникальных значений ключевых полей - спасибо за подсказанное направление. Буду мыслить туда, кажется там есть определенные перспективы. Конечно, при большом числе записей в таблицах такой метод не подойдет, но у меня как раз случай с небольшим числом записей (до 300).
Еще раз благодарю. Думаю, можно тему считать закрытой.