Людмila,

Да запрос вроде простой.

Пример открыьтя таблиц:
USE pcBdSchedulesPath+"_put_list.dbf" SHARED IN 4001 ALIAS bd_schedules_apl_loc


Пример запроса (выполняется в цикле по периодам и внутри каждого периода по отделам)
SELECT;
bd_schedules_apl_loc.apl_id,;
bd_schedules_apl_loc.apl_stats,;
bd_schedules_apl_loc.apl_numb,;
bd_schedules_apl_loc.apl_name,;
bd_schedules_apl_loc.apl_datetm,;
bd_schedules_apl_loc.apl_datego,;
bd_schedules_apl_loc.rep_ocens,;
bd_schedules_apl_loc.kol_banks,;
(IIF(bd_schedules_apl_loc.kol_banks>0,bd_schedules_apl_loc.kol_banks,cur_sum_clnt.sum_clnt))sum_clnt,;
bd_schedules_otdels.otdel_code,;
bd_schedules_otdels.work_srok,;
bd_schedules_otdels.work_id,;
nsi_type_work.group_name,;
cur_lost_requery.max_daterq,;
({..})date_norm,;
(0)isp_stats,;
cur_lost_query.no_requer;
FROM ;
bd_schedules_apl_loc;
INNER JOIN bd_schedules_otdels;
ON bd_schedules_apl_loc.apl_id = bd_schedules_otdels.apl_id ;
INNER JOIN nsi_type_work ;
ON bd_schedules_otdels.work_id = nsi_type_work.id_work;
left OUTER JOIN cur_sum_clnt;
ON bd_schedules_apl_loc.apl_id = cur_sum_clnt.apl_id ;
left OUTER JOIN cur_lost_requery;
ON bd_schedules_apl_loc.apl_id = cur_lost_requery.apl_id ;
left OUTER JOIN cur_lost_query;
ON bd_schedules_apl_loc.apl_id = cur_lost_query.apl_id ;
WHERE bd_schedules_apl_loc.apl_stats = "закрыто";
AND bd_schedules_apl_loc.apl_datego BETWEEN pdDateRepStart AND pdDateRepFinish;
AND bd_schedules_otdels.otdel_stat = 1;
AND bd_schedules_otdels.otdel_base = "1";
AND bd_schedules_otdels.otdel_code = ALLTRIM(lcOtdelCode);
AND bd_schedules_apl_loc.wiev_code # "1";
INTO CURSOR cur_stat1 READWRITE


Комментарий:
bd_schedules_apl_loc - основная таблица со списком дел
bd_schedules_otdels - таблица со списком отдлов-исполнителей
nsi_type_work - таблица НСИ с видами работ
cur_lost_query, cur_lost_requery - курсоры с датами запросов и ответов по делам
cur_sum_clnt - курсос с кол-вом клиентских записей для каждого дела

Dima T,

Оптимизатор выдаёт следующее:
--------------------------------------------------------------------------------------
Rushmore optimization for table bd_schedules_apl_loc: none
Rushmore optimization for table bd_schedules_otdels: none
Rushmore optimization for table nsi_type_work: none
Rushmore optimization for intermediate result: none
Rushmore optimization for intermediate result: none
Rushmore optimization for intermediate result: none
Joining table nsi_type_work and table bd_schedules_otdels using temp index
Joining intermediate result and table bd_schedules_apl_loc using temp index
Joining intermediate result and intermediate result using temp index
Joining intermediate result and intermediate result using temp index
Joining intermediate result and intermediate result using temp index
--------------------------------------------------------------------------------------

Число записей в основной таблице - около 15 тыс.
В результирующем запросе - 5 - 9 (в зависимости от одела)

Запрос выполняется в 4х7 цикла, каждый примерно по 6-7 секунд (при запуске приложения несколькими пользователями)
В итоге и набегает около 3 минут.

Dima T,

Индексы я не ставил по двум причинам: 1. в индексированных таблицах замедляются операции ввода и редактирования данных, 2 - при добавлении новых записей необходима повторная переиндексация, что подразумевает отключение от базы всех пользователей.
В данном варианте исполнения приложения это не совсем удобно. В дальнейшем возможно база будет разделена на текущую (куда добавляются и редактируются новые записи) и архивную (закрытые дела, по которым редактирование осуществляется крайне редко). Быть может тогда стоит применить индексирование к архивной части базы, т.к. данный запрос формируется именно по закрытым делам.

Согласен, что процес запроса "цикл в цикле" не совсем удачное решение. К сожаленю, так построена структура формирования отчёта. С другой стороны, при одиночном использовании приложения этот запрос выполняется за 20-25 секунд (от момента запуска до открытия готового отчёта в excel). Это нормально по сравнению с 3-8 минутами (при коллективном использовании приложения).
Т.е. сам запрос отрабатывает относительно быстро (понятно, что при индексации будет ещё быстрее). Не понятна причина, по которой разница по времени возрастает раз в 20, когда подключается хотябы ещё 1 пользователь.

Dima T,

по WHERE меняется сначала период (1 квартал, 2, 4 или 4), а внутри код отдела, для которого формируется отчёт.

например,
выбрали 1-й квартал.
для периода с 01/01 по 31/03 в цикле для каждого отдела выгружаются данные и записываются на разные листы в excel в столбец А

Выбрали 2-й квартаол
для периода с 01/01 по 31/03 в цикле для каждого отдела выгружаются данные и записываются на разные листы в excel в столбец А
для периода с 01/04 по 30/06 в цикле для каждого отдела выгружаются данные и записываются на разные листы в excel в столбец B

и т.д.

Dima T,

Да, читал. Просто на столько явное расхождение по времени и неужеди всё уходит на сеть...

Изначально индексирование не рассматривалось. Были несколько другие задачи и объёмы. + слышал не очень-то лестные отзывы о работе с индексированными таблицами: периодически индексы падали... А так, да. Но скорее для варианта с разделёнными базами.

В любом случае, Dima T, спасибо.

AndreTM,

В книгах по Фоксу читал, но сейчас уже не помню в каких именно.