AndreTMDmDeDВ книгах по Фоксу читал, но сейчас уже не помню в каких именно.Видимо, вы читали не те книги
В книгах есть упомянутые фразы, но в данном случае они очень бездумно вырваны из контекста сказанного в книгах.
DmDeD, советую перечитать и осмыслить все что написано про использование индексов.

DmDeDНо основная проблема, как я понял, связанна с сеткой?
Да
DmDeDДопускаю, что с индексами будет работать гораздо быстрее... Вот интересно проверить сколько покажет тестирование по времени в многопользовательском режиме... (меньше 8 минут?)
Создай индекс и проверь :) Индекс уменьшает нагрузку на сетку.
Главное ускорение от индексов в том что фокс качает сначала индекс (не весь, а только нужную часть), получает из него какие записи надо скачать и затем качает только нужные, а не все.
Например в твоем селекте:


без индекса: клиент полностью скачает к себе таблицу bd_schedules_apl_loc и после будет делать выборку перебором записей.
Если бы был индекс по bd_schedules_apl_loc.apl_datego: клиент скачает индекс, получит какие записи нужны и скачает только эти записи.
Т.е. чем меньше записей попадает под условие выборки тем быстрее будет выборка.

Что касается ключевых индексов по справочникам (bd_schedules_otdels.apl_id и nsi_type_work.id_work) то у тебя фокс сначала скачивает всю таблицу, затем создает для нее временный индекс, о чем оптимизатор и написал: "Joining table nsi_type_work and table bd_schedules_otdels using temp index"
Если бы индекс был, то был бы скачан индекс, а по нему только требуемые записи.

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

Например если продолжить мой тестовый пример и создать индекс по nKol, то в случае нескольких пользователей вместо 55 сек получается 6,1 сек и трафик 6.5 Мб вместо 207 Мб. (результат выборки 22 тыс. записей из 7.8 млн)

DmDeDDima T,

с проиндексорованной таблицей получилось 1:28 вместо 2:35
на 40% уже результат. Правда 1:28 тоже многовато.
Думаю в твоем случае самый быстрый способ это один раз сделать предварительную выборку в курсор, курсор проиндексировать по дате, а затем из него строить отчет в циклах. Главный тормоз все-таки сетка. Если один твой запрос без индексов делается 6-7 сек. при этом затягивая всё на клиента, то предварительная выборка будет не намного дольше. Зато последующие из курсоров будут выполнятся намного быстрее и их скорость никак не будет зависеть от того сколько пользователей работает. Т.е. максимум должно получится нормальные для тебя 25 сек плюс 10-15 сек на предварительную выборку. Хотя возможно все вместе будет быстрее 25 сек.

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

DmDeDпоходу сначала придётся перепроектироваться всю структуру БД и понять, что индексировать
Структуру не надо менять.
Минимально индекс должен быть на ключевом поле. А для остальных полей смотреть какие фильтры в запросах используются (WHERE) и для часто используемых полей добавлять индексы.

rewareНу а чё не пишешь, первый-то комп всё ещё пашет ? Пашет ТОЛЬКО второй комп ? Ну, чё, как дитё малое, нормально не можешь описать свой эксперимент и результаты ? Да пиши по-русски, в конце концов "Включил 1 комп, результаты такие-то, выключил его, включил второй комп - результаты твкие-то, включил задачу на двух компах - результаты такие-то...". Ну, фигня, согласись, то, что ты приложил (цифры) здесь, ну можно по-разному трактовать.
Я могу понять нежелание повторить, но нежелание просто внимательно прочитать написанное - это уже хамство.
Вроде однозначно написал:
Dima T На своем компе открыл фокс и запускал замер по три раза для каждой ситуации.
т.е. тестовый код ВСЕ разы запускался на моем компе. На втором просто открывал/закрывал таблицу. Чего делал на втором тоже писал:
Dima T1. Таблица открыта только у меня: 22 сек, 1.1 сек, 1.1 сек
2. Открыл на втором (только use \\Server\Share\test.dbf shared): 55 сек, 55 сек, 55 сек
3. Закрыл на втором (use in test и закрыл фокс): 55 сек, 55 сек, 55 сек
4. Закрыл таблицу на своем (use in test): 22 сек, 1.1 сек, 1.2 сек

rewareНу, фигня, согласись, то, что ты приложил (цифры) здесь, ну можно по-разному трактовать.
Давай свою трактовку. Только сначала перевари все что я написал.

ЗЫ По времени в Хабаровске 12-й час ночи, ты сначала выспись, потом ответишь.

DmDeDDima T,

Я предполагал проводить повторное индексирование на этапе администрирования в начале операционного дня
Обычно как-то так и делается. Раз в сутки достаточно.
Я обычно делаю запуск заданием на сервере при включении сервера (если на ночь отключается) или ночью (если круглосуточно работает). Во втором случае возможно что кто-то из пользователей прогу не закроет, тогда проиндексировать не получится.