Hi Sea.Starry!

По первому вопросу - это штатное поведение - сделано для того, чтобы при
связи 1-ко-много можно было "ходить" (SKIP например) по главной таблице и
при этом попадать на ВСЕ записи дочерней таблицы - конечно по очереди. При
этом для "красоты отображения" исторически делается хитрая штука - для
главной таблицы выводятся данные только в первой записи в каждой группе - в
остальных выводятся "звёзды".
Для твоего случая всё очень просто - не надо использовать SET SKIP - тогда
первый грид будет как-бы фильтровать второй - т.е. по мере движения в первом
(где не будет дублей) во втором будут появляться записи связанные с текущей.
НО твой вариант с Local View IMHO более предпочтителен в любом случае.
Правда при этом:
1) В качестве параметра можно указывать не только переменную, но и поле
любой "внешней" (по отношению к самому запросу) таблицы - т.е. можно было в
SQL прописать where device_id = ?MasterTable.device_id
2) Если используешь макро, то его надо точкой завершать а не пробелом - т.е.
надо не

> lcval = &lcAlias .device_id

а

lcval = &lcAlias..device_id

При этом первая точка это просто символ-терминатор для макро - а вто вторая
уже служит разделителем алиаса и имени поля.

3) Лучше макро не использовать - есть масса вариантов:

lcval = EVALUATE(m.lcAlias + ".device_id")
или

SELECT (m.lcAlias)
lcval = device_id

или

STORE (m.lcAlias + ".device_id") TO lcval

> Насколько это оправдано

Использование LocalView для реализации "подчинённых" (а равно и основных!)
источников данных вполне оправдано - главное следить за своевременным
сохранением данных из этих курсоров (конечно если они обновляемые, а не
ReadOnly) - особенно для тех которые перезапрашиваются в AfterRowColChange.

Posted via ActualForum NNTP Server 1.3