RDLC over RDLレポートを使用する場合
私は過去数週間にSSRS 2005/2008を研究しており、いくつかのサーバーサイドレポートを作成しました。一部のアプリケーションでは、同僚がその特定の状況についてRDLCを調べることを提案しました。現在、RDLとRDLCの主な違いについて理解しようとしています。
この情報を検索すると、せいぜい断片化された情報が得られます。私はそれを学んだ：
- RDLCレポートには、データの取得方法に関する情報は保存されません。
- RDLCレポートは、ReportViewerコントロールによって直接実行できます。
しかし、RDLCファイルと他の関連システム（Reporting Server、ソースデータベース、クライアント）との関係をまだ完全には理解していません。
RDLCファイルをよく理解するために、その使用がRDLファイルとどのように異なり、どのような状況でRDLよりもRDLCを選択するかを知りたいと思います。リソースへのリンクも歓迎します。
更新：
ASP.NETフォーラムのスレッド は、この同じ問題について説明しています。それから、私はこの問題についてより良い理解を得ました。
RDLCの機能は、ReportViewerコントロールで完全にクライアント側で実行できることです。
- これにより、Reporting Servicesインスタンスが不要になり、データベース接続も不要になりますが、次のようになります。
- レポートに必要なデータを手動で提供する必要があるという要件が追加されます。
これが利点か欠点かは、特定のアプリケーションによって異なります。
私のアプリケーションでは、とにかくReporting Servicesのインスタンスを使用でき、レポートに必要なデータをデータベースから簡単に取得できます。 RDLCを検討する理由はありますか、それとも単にRDLに固執する必要がありますか？
私の経験から、両方のことについて考えることはほとんどありません。
I. RDLレポートは、一般にホストされたレポートです。つまり、SSRSサーバーを実装する必要があります。これらは、SQL Serverのレポート言語用のVisual Studioの組み込み拡張機能です。 SSRSをインストールするときに、「Business Intelligence Development Studio」というアドオンを用意する必要があります。これは、レポートを使用しない場合よりもレポートを使用する方がはるかに簡単です。
Report
D定義
Langauge
RDLレポートの利点：
- サービスは、サービスが実行されている環境でホストできます。
- スタンドアロンの概念としてセキュリティを処理するために、アイテムまたは継承レベルでセキュリティを構成できます
- 電子メールを送信するようにサービスを構成し（アクセスできるSMTPサーバーがある場合）、スケジュールに従ってファイルを保存できます。
- 一般に「ReportServer」と呼ばれるデータベースがあり、公開されたレポートに関する情報を照会できます。
- これらのレポートには、ASP.NET、WPF（winformコントロールbleh！）で記述されたクライアントアプリケーションの「ReportViewer」、または「ProcessingMode.Remote」を使用して.NETのWinformsからアクセスできます。
- ユーザーが表示および使用できるパラメーターを設定して、柔軟性を高めることができます。
- 接続文字列に使用するレポートの一部を「データソース」として、SQLクエリ、xml、またはその他のデータセットを「データセット」として使用するように構成できます。これらの部品およびその他の部品は、定期的にデータをキャッシュするように保存および構成できます。
- サービスの.NETプロキシクラスhttp：///ReportServer/ReportingService2010または/ ReportExecution2005を作成できます。その後、コードでSSRSレポートをホストするサーバーのサービスから直接SSRSデータを電子メールで送信、保存、または操作するために、.NETで独自のメソッドを作成できます。 ReportService2010.asmxを使用して共有ポイントからSSRSレポートをプログラムでエクスポート
欠点：
- SSRSは、それを高速に起動することに関して、他のものと比較して一種のワンキーです。ほとんどの人は、セキュリティポリシーと、VSへの「アドオン」としてのレポートの設計に混乱します。 SQL 2005 = VS BIDS 2005、SQL 2008 = VS BIDS 2008、SQL 2012 = VS BIDS 2010（LOL）。
- セキュリティ設定IMHOのポリシーを1に続けると、ばかげて複雑になりすぎます。サービス用にホストされるページには、サーバーセキュリティ、データベースセキュリティ、およびロール、2つのセキュリティ設定があります。ほとんどの人は、管理者を設定するだけで、他のユーザーは管理できないのではないかと考えます。 SSRSに関する最も一般的な苦情や質問は、私の経験から一般的に取得することに関連しています。
- レポートを「強化」する「式」を使用できます。多くの場合、複数の操作を行うと、レポートのパフォーマンスが低下します。
- できることやエクスポートできることは決まっています。 SSRSは、javascriptのハッキングなしで、私が知っているレポートにカーソルを合わせています。
- 愚かなSSRS構成がシステムをリサイクルするため、速度とパフォーマンスが打撃を受ける可能性があります。最初のレポートは、サイトをロードするだけでしばらく時間がかかることがあります。これを変更することで回避できますが、キープアライブサービスを作成するとより効果的です。
II。 RDLCレポートは、どこにもホストされていないクライアント包含レポートです。名前の余分なcは「クライアント」を意味します。通常、これはVisual Studioクライアントアプリケーションでのみ使用することを目的としたRDL言語の拡張です。 「レポート」アイテムを追加すると、Visual Studioに存在します。
RDLCレポートの利点：
- データセットにはるかに簡単にwcfサービスを接続できます。
- データセットをより細かく制御し、Entity frameworkオブジェクトまたはADO.NETで満たされたPOCOクラスを直接使用することも、テーブル自体を使用することもできます。レポートにバインドする前に、最適化のためにデータを取得できます。
- コードビハインドでアドオンを直接使用して、外観をさらにカスタマイズできます。
欠点：
- 自分でパラメータを処理する必要がありますが、ラッパーメソッドを実装してレッグワークを支援することは期待以上であり、残念です。
- ユーザーは、リモートモードでRLDレポートにアクセスしない限り、「ReportViewer」コントロールのパラメーターを見ることができません。したがって、テキストボックス、ドロップダウン、ラジオボタンをコントロールの外部で独自に作成して、そこに渡す必要があります。このようなコントロールを追加した人の中には、私は個人的にはしません。
- 配布用のレポートのサービスでやりたいことは、自分で作成する必要があります。メール、サブスクリプション、保存。申し訳ありませんが、それを.NETで構築する必要があります。そうでない場合は、上記のプロキシを実装する必要があります。
正直なところ、私は両方が異なる目的で好きです。常に使用しているアナリストに何かを出し、グラフ、チャート、ドリルダウン、ExcelへのエクスポートにTweakを使用したい場合は、RDLを使用し、SSRSのサイトにメール配信を処理するすべての作業を任せます。レポートセクションがあるアプリケーションが必要で、そのアプリケーションがルールとガバナンスを備えた独自のモジュールであることがわかっている場合は、RDLCを使用し、パラメーターを小さくして、レポートの一部に到達する前にユーザーが下した決定によって駆動されるようにしますクライアントはサイトにいて、通常は時間枠またはタイプを選択するだけで、それ以上は選択しません。したがって、一般に複雑なレポートではRDLを使用し、単純なレポートではRDLC IMHOを使用します。
それがお役に立てば幸いです。
Q：RDL形式とRDLC形式の違いは何ですか？
A：RDLファイルは、SQL Server 2005バージョンのレポートデザイナーによって作成されます。 RDLCファイルは、Visual Studio 2008バージョンのレポートデザイナーによって作成されます。
RDLおよびRDLC形式は同じXMLスキーマを持っています。ただし、RDLCファイルでは、一部の値（クエリテキストなど）を空にすることができます。つまり、すぐにレポートサーバーに公開する準備ができていません。欠損値は、SQL Server 2005バージョンのレポートデザイナーを使用してRDLCファイルを開くことで入力できます。 （最初に.rdlcの名前を.rdlに変更する必要があります。）
RDLファイルは、ReportViewerコントロールランタイムと完全に互換性があります。ただし、RDLファイルには、ReportViewerコントロールのデザインタイムがデータバインディングコードを自動生成するために依存する情報が含まれていません。データを手動でバインドすることにより、RDLファイルをReportViewerコントロールで使用できます。新着！ RDL Viewerサンプルプログラムも参照してください。
ReportViewerコントロールには、データベースに接続したりクエリを実行したりするためのロジックが含まれていないことに注意してください。このようなロジックを分離することにより、ReportViewerは、非データベースデータソースを含むすべてのデータソースと互換性があります。ただし、これは、ReportViewerコントロールがRDLファイルを使用する場合、RDLファイル内のSQL関連情報がコントロールによって単に無視されることを意味します。データベースへの接続、クエリの実行、およびADO.NET DataTablesの形式でReportViewerコントロールへのデータの提供は、ホストアプリケーションの責任です。
RDLとRDLCの違いは、RDLがSQL Server Reporting Servicesに使用され、RDLCがVisual Studioでクライアント側のレポートに使用されることだと常に考えてきました。実装とエディターはほぼ同じです。 RDLは、レポート定義言語およびRDLCレポート定義言語のクライアント側を表します。
それがお役に立てば幸いです。
私の経験から、大きなレポートで高いパフォーマンスが必要な場合（これはクライアントの仕様にわずかに依存します）、rdlcを使用してください。さらに、rdlcレポートを使用すると、データを非常に完全に制御できます。クライアント側のレポートを使用して、無駄なデータベース旅行などを保存できる場合があります。私が現在取り組んでいるプロジェクトでは、重要なレポートがサーバー側でレンダリングするのに約2分かかり、その間にヒットしたレポートサーバーをほとんど削除します。クライアント側のレンダリングに切り替えると、レポートサーバーに負荷がかからず、データセットのみがダウンロードされるため、使用される帯域幅が少なく、20〜40秒に近いパフォーマンスが得られます。
走行距離は異なる場合があり、特にレポートがサーバー側のレポートとして設計されている場合、rdlcの開発とメンテナンスの複雑さが加わることがわかります。
これらのポイントのいくつかは上記で対処されましたが、VS2008環境の2セントです。
RDL（リモートレポート）：はるかに優れた開発エクスペリエンス、スケジューリング、アドホックレポートなどの高度な機能を使用する必要がある場合の柔軟性.
RDLC（ローカルレポート）：データをレポートに送信する前にデータをより適切に制御します（レポートに送信する前にデータを検証または操作しやすくなります）。はるかに簡単な展開。ReportingServicesのインスタンスは不要です。
ローカルレポートに関する1つの大きな警告は、クライアントが多数の大きなレポートを実行する場合にパフォーマンスに深刻な影響を与える可能性がある既知のメモリリークです。これは、レポートビューアーの新しいVS2010バージョンで対処することになっています。
私の場合、Reporting Servicesのインスタンスを利用できるため、新しいレポートをRDLとして開発し、ローカルレポートに変換して（簡単です）ローカルレポートとして展開します。
私は現在より柔軟で管理しやすいためRDLに傾いていますが、RDLCにはライセンスを簡素化できるという利点があります。 RDLCはReporting Servicesインスタンスを必要としないため、それを使用するためにReporting Servicesライセンスは必要ありません。
これがSQL Serverの新しいバージョンにまだ当てはまるかどうかはわかりませんが、SQL ServerデータベースとReporting Servicesインスタンスを2つの異なるマシンに配置することを選択した場合、2つの異なるSQL Serverライセンスが必要でした：
http://social.msdn.Microsoft.com/forums/en-US/sqlgetstarted/thread/82dd5acd-9427-4f64-aea6-511f09aac406/
Bing は、Reporting Servicesライセンスに関する他の同様のブログおよび投稿に使用できます。
レポートサービスインフラストラクチャを利用できる場合は、それを使用します。 RDL開発はもう少し快適であることがわかります。レポートをプレビューしたり、パラメーターを簡単に設定したりできます。
VS2008の場合、RDLはRDLCよりも優れた編集機能を提供すると考えています。たとえば、RDLを使用してテキストボックス内の選択したテキストの太字を変更できますが、RDLCではできません。
RDL：abcd efgh ijklmnop
RDLC：abcd efgh ijklmnop-または-abcd efgh ijklmnop（唯一のオプションです）
これは、RDLCが2005年から以前のネームスペース/フォーマットを使用し、RDLが2008を使用しているためです。ただし、これはVS2010で変更されます
Asp.net Webページで使用される複雑さの少ないレポートの数が少ない場合。 rdlcを使用することをお勧めします。理由は、RSインスタンスに関するレポートの保守を避けることができるからです。ただし、DBからデータを手動で取得し、rdlcにバインドする必要があります。
短所：Visual Studioでのrdlcの設計は、SSrsデザイナーに比べて少し難しいです。
Pro：メンテナンスは簡単です。ページからレポートをエクスポートする際、サーバー側のレポートと比較してパフォーマンスが向上することが観察されました。