Я закодировал около десятка отчетов, основанных на сотрудниках, и окончательный результат был отправлен в Excel.
Возникло новое требование расширить эти отчеты, добавив вторую вкладку, которая включает как сотрудников, так и подрядчиков, а Первая вкладка продолжает показывать только сотрудников. В прошлом я обычно обрабатывал подобные вещи, добавляя поле TAB (= 1 или = 2) к набору данных, модифицировал запрос, включив в него все необходимые данные и заполнив поле табуляции, а затем, в определении отчета, добавил группа в новом поле TAB на самом высоком уровне (над существующими группами) в отчете. По причинам, которыми я не буду вас обременять, я не могу использовать этот подход в этом случае.
Поэтому я решил добавить параметр в отчет (@ Tab = 1 или @ Tab = 2). Я устанавливаю @ Tab = 1 (в параметре default), затем в конце отчета получаю, что он вызывает сам себя, но передает параметр @ Tab = 2. Подотчет условно скрыт, если @ Tab = 2 (то есть нет необходимости вызывать его еще раз, если в данный момент он генерирует вторую вкладку). Этот подход отлично работал на всех столбцах одного из отчетов.
Отчет о проблеме все еще выполняется до конца и генерирует требуемые результаты, но для его запуска в среде разработки требуется более 4 минут. Если я удаляю вложенный отчет, он запускается примерно через 20 секунд, независимо от того, установлено ли @Tab на 1 или 2. Это подсказывает мне, что при запуске с вложенным отчетом он должен выполняться менее чем за минуту. Только в качестве эксперимента я создал дубликат отчета и изменил отчет так, чтобы он вызывал дубликат (а не сам по себе), но у меня появились те же симптомы. Журнал выполнения предполагает, что большая часть из 4 минут уходит на поиск данных. Если я скрываю подотчет безоговорочно, то продолжительность не изменяется - это говорит о том, что любое бремя, инициируемое подотчетом, вызывается независимо от того, вызывается ли оно на самом деле или нет.
Я успешно сгенерировал «основной» отчет по сути это оболочка, которая вызывает подчиненный отчет (который выполняет всю тяжелую работу) дважды - один раз с @ Tab = 1, а затем снова с @ Tab = 2. Это дает правильный результат за 40 секунд. Однако меня попросили найти решение, которое не включает в себя создание дополнительного отчета.
Я поместил запрос в хранимую процедуру и предпринял шаги, чтобы уменьшить любой «анализ параметров», но эти шаги не помогли. Журнал выполнения указывает на запрос - то есть время извлечения данных велико. Запрос выполняется в SSMS за 10 секунд.
Я уже потратил 2 дня на это и буду благодарен за любые мысли или предложения. Большое спасибо.