кто сталкивался с этой проблемой и нашёл решение, помогите, пожалуйста!

не вошло, сорри...

если отчет не очень сложный, то SELECT (SQL) into cursor или построить вид, оба значительно сокращают видимое колличетсво таблиц

Вообще, вариант предложенный СВ - это наиболее правильный способ работы с генератором отчетов VFP.
Т.е. ПЕРЕД печатью формировать временную таблицу через SQL-запросы и ее печатать.
Просто в PRG значительно легче отследить все изменения и модификации чем в сильно навороченном отчете.

Я всегда так и делаю... но теперь запрос не вывозит... слишком много таблиц надо обработать... SOS!

ДЮС, возможно, я повторяюсь, но кто тебе мешает делать PRG и в нем выполнять сколько угодно запросов в любой последовательности, а затем вызывать REPORT или сообщить почему это невозможно.
Т.е. вместо вызова непосредственно REPORT, ты вызываешь PRG, а из PRG сам REPORT.

Получение результата за один запрос - это идеальный случай, НО :
1. Это не всегда возможно
2. Даже если это возможно, не всегда это самый быстрый способ и быстрее выполняется несколько последовательных запросов, чем один большой.
3. Если один запрос чрезвычайно сложен, то иногда стоит разбить его на несколько запросов для удобства понимания и редактирования в будущем.

Вообще стоит понять, что хотя SQL-запрос и наиболее удобное средство работы с базами данных не стоит относится к нему как к единственно возможному способу. Если при его использовании программа чрезмерно усложняется или слишком замедляется, следует рассмотреть альтернативные варианты (почти всегда они есть!)

Например, в твоем случае, может быть стоит рассмотреть такой сценарий:
Создать ПУСТУЮ таблицу, а затем ее заполнить сканированием базы данных (очень часто - это самый простой и самый быстрый способ)