Производительность SSRS с несколькими наборами данных
CLR любит оптимизировать инструкции, поэтому при доступе к полю в коде он может не всегда получать доступ к текущему значению поля (это может быть из стека и т. д.). Маркировка поля как volatile гарантирует, что текущее значение поля будет доступно инструкцией. Это полезно, когда значение может быть изменено (в сценарии без блокировки) параллельным потоком в вашей программе или другим кодом, запущенным в операционной системе.
Вы, очевидно, теряете некоторую оптимизацию, но это делает сохраните код более простым.
1 ответ
я хотел бы сделать следующее: предположив, что 10 RDL выполняют 10 различных хранимых процедур, назначьте каждой хранимой процедуре скрытый параметр. давайте назовем это @report_number (например). Поэтому для первого отчета в хранимой процедуре добавьте предложение where для включения and @report_number = 1, что должно технически остановить хранимую процедуру, как только она увидит, что передано другое число (скажем, 2 для отчета 2) ... и так далее, и так далее ..
@report_number назначается в отдельном наборе данных.
например,
report1 - значение = 1
report2 - значение = 2
.
.
.
report10 - значение = 10
, поэтому, когда пользователь запускает отчет 1, значение 1 для @report_number передается в этот набор данных. Остальные наборы данных не должны запускать связанную с ним процедуру как они не будут иметь ожидаемого значения в предложении where.
Надеюсь, что это имело смысл.