私はこの問題を回避しようとしてきましたが、ここの誰かが同じ問題を解決してくれることを期待していました。
私の SSRS レポートには、動的に設定されるデフォルト パラメータがいくつかあります。何が起こっているかというと、レポート ページが最初に開かれると (これらのレポートはカスタム Web アプリから実行されます)、「メイン」レポート sproc が 1 回起動され、それらの 2 ～ 3 個の動的パラメーターを取得するだけです。その sproc がこの時点で表示されます (これがやり過ぎだと思われる場合は、... これらのレポートを設計した元同僚からこれらのレポートを継承しました)。したがって、2 ～ 3 個の動的パラメーターがあるため、レポートはクエリからこれらの既定値を取得するように設計されています。そのため、最終的にユーザーがレポートを実行するまでに、メイン sproc (簡単にするために「report_getReportData」と呼びます) は、ページにレンダリングされる前に既に約 3 ～ 4 回実行されています。
私がしたことは、report_getReportData sproc 内で、select * ステートメントを実行してすべてのレポート データを表示する前に、2 ～ 3 個のデフォルト値を保持する物理テーブルを作成し、レポートに新しいデータセットを作成して、この物理テーブルから値を選択するだけの新しい sproc で、他には何もないため、結果として、getReportData sproc は 1 回だけ起動し、新しい sproc を「report_getTwoParameters」と呼びましょう。パラメータごとに 1 回起動しますが、時間コストは無視できるためは、1 つのクイック選択ステートメントを実行するだけです。
これにより、レポート全体のパフォーマンスの問題は解決されましたが、物理テーブルが関係しているため (report_getReportData は一時テーブルからデータを返します)、複数のユーザーがこのレポートを同時に実行できないという問題に直面しています。したがって、私の投稿には2つの質問があると思います。
1) レポートで report_getReportData を実行して 2 ～ 3 個のパラメーターを設定する必要があるという主な問題を回避する方法はありますか?たとえば、sproc から返された結果セットをいくつかの異なるデータセットに「マルチキャスト」するなど、
2) 物理テーブルを使用するという私の解決策を維持することにした場合、ユーザーがレポートを同時に実行できるが、この同じ物理テーブルにぶつからないようにするために、これに対する代替解決策はありますか?