Quand faut-il utiliser RDLC sur RDL rapports ?

Question

J'ai été étudiant SSRS 2005 / 2008 dans les dernières semaines et ont créé certains de côté de serveur de rapports. Pour certaines applications, un collègue m'a suggéré de regarder dans RDLC pour cette situation particulière. Je suis maintenant essayer d'obtenir ma tête autour de la principale différence entre la RDL et RDLC.

La recherche de cette information donne des informations fragmentaires, au mieux. J'ai appris que:

• RDLC rapports n'enregistre pas d'informations sur la façon d'obtenir les données.
• RDLC rapports peuvent être exécutés directement par le contrôle ReportViewer.

Mais je continue à ne pas bien comprendre la relation entre le fichier RDLC et les autres systèmes connexes (le Serveur de Rapports, la source de base de données, le client).

Afin d'obtenir une bonne prise sur RDLC fichiers, je voudrais savoir comment leur utilisation diffère de fichiers RDL et dans quelle situation on pourrait choisir RDLC sur RDL. Des liens vers des ressources sont également les bienvenus.

Mise à jour:

Un thread sur le ASP.NET forums traite du même sujet. Depuis, j'ai acquis une meilleure compréhension sur la question.

Une fonctionnalité de RDLC est qu'il peut être exécuté complètement à côté client dans le contrôle ReportViewer.

• Cela supprime la nécessité d'une instance de Reporting Services, et même supprime le besoin pour n'importe quelle connexion à la base que ce soit, mais:
• Il ajoute l'exigence que les données qui sont nécessaires dans le rapport doit être fournie manuellement.

Si c'est un avantage ou un inconvénient dépend de l'application.

Dans mon application, une instance de Reporting Services est à votre disposition de toute façon et les données requises pour les rapports peuvent facilement être retirés à partir d'une base de données. Est-il plus aucune raison pour moi d'envisager RDLC, ou devrais-je simplement coller avec de la RDL?

Answer 1

De mon expérience, il ya quelques choses à penser deux choses:

I. rapports RDL sont HÉBERGÉS les rapports en général. Cela signifie que vous devez mettre en œuvre Serveur SSRS. Ils sont construits en extension de Visual Studio à partir de SQL Server pour le reporting language. Lorsque vous installez SSRS, vous devriez avoir un add-on appelé "Business Intelligence Development Studio" qui est beaucoup plus facile de travailler avec les rapports que sans elle.

R apport

D efinition

L angauge

Avantages de la RDL rapports:

1. Vous pouvez héberger les rapports dans un environnement qui a des services en cours d'exécution pour vous.
2. Vous pouvez configurer la sécurité sur un élément ou d'en hériter niveau pour gérer la sécurité comme un concept autonome
3. Vous pouvez configurer le service pour envoyer des e-mails(à condition d'avoir un serveur SMTP, vous avez accès) et de sauvegarder des fichiers sur les horaires
4. Vous avez une base de données généralement appelé "ReportServer' vous pouvez faire une requête pour l'info sur les rapports une fois publié.
5. Vous pouvez accéder à ces rapports, toujours par l'intermédiaire de 'ReportViewer" dans une application client écrit en ASP.NET WPF (avec un contrôle winform bleh!), ou Winforms .NET à l'aide de 'ProcessingMode.De distance".
6. Vous pouvez définir les paramètres d'un utilisateur peut voir et utiliser pour avoir plus de souplesse.
7. Vous pouvez configurer des parties d'un rapport destiné à être utilisé pour les chaînes de connexion comme "Sources de Données" ainsi que d'une requête sql, xml, ou d'autres ensembles de données comme un "Dataset'. Ces pièces et d'autres peuvent être stockées et configuré pour mettre en cache les données sur une base régulière.
8. Vous pouvez écrire .NET proxy classes de services http:// /ReportServer/ReportingService2010 ou /ReportExecution2005. Vous pouvez ensuite créer vos PROPRES méthodes .NET pour le courrier électronique, l'enregistrement ou la manipulation de données SSRS du service directement d'un Serveur d'hébergement de rapports SSRS dans le code. Par programme d'Exportation de rapports SSRS à partir de sharepoint à l'aide de ReportService2010.asmx

Inconvénients:

1. SSRS est une sorte de wonkey par rapport à d'autres choses démarrage rapide. La plupart des gens se confondre par la politique de sécurité et la conception de rapports, comme un 'add on' pour VS. SQL 2005 = VS D'OFFRES DE 2005 , SQL 2008 = VS D'OFFRES DE 2008, SQL 2012 = VS D'OFFRES DE 2010(LOL).
2. Continuer sur 1 la politique pour les paramètres de sécurité à mon humble avis sont idiotement overcomplex. Il y a de la sécurité du serveur, de la base de données de sécurité et les rôles, les deux paramètres de sécurité sur la page hébergée par le service. La plupart des gens n'a mis en place un admin de ne peut pas entrer et se demandent pourquoi les autres utilisateurs ne peuvent pas. La plupart des communes de la plainte ou de la question sur SSRS est lié à l'obtention, dans l'ensemble de mon expérience.
3. Vous pouvez utiliser les "expressions" supposeduly "améliorer" votre rapport. Souvent vous n'avez plus que quelques et votre rapport d'analyse de la performance.
4. Vous avez une quantité de choses que vous pouvez faire et de l'exportation. SSRS a pas de planer sur les rapports que je connais sans javascript hack.
5. La vitesse et les performances peuvent en prendre un coup, comme le stupide SSRS config recycle le système, et un premier rapport peut prendre un certain temps à la fois tout le chargement du site. Vous pouvez contourner ce problème en modifiant mais j'ai trouvé que faire un keep alive service pour qu'il fonctionne mieux.

II. RDLC rapports sont CLIENT contient les rapports qui ne sont PAS HÉBERGÉ n'importe où. Le supplément c au nom signifie "Client". Généralement c'est une extension de la RDL langue signifiait seulement pour une utilisation dans les Applications clientes Visual Studio. Il existe dans Visual Studio lorsque vous ajoutez un "reporting" de l'élément.

Avantages de la RDLC rapports:

1. Vous pouvez accrocher un service wcf beaucoup beaucoup beaucoup plus facile à l'ensemble de données.
2. Vous avez plus de contrôle sur le jeu de données et peuvent utiliser des classes POCO rempli avec Entity framework, des objets ou des ADO.NET directement ainsi que des tableaux eux-mêmes. Vous pouvez le singe avec les données pour l'optimisation avant de liaison pour le rapport.
3. Vous pouvez personnaliser l'apparence de plus à ajouter directement dans le code derrière.

Inconvénients:

1. Vous avez besoin de gérer les paramètres sur votre propre et tandis que vous pouvez mettre en œuvre les méthodes de wrapper pour aider le travail sur le terrain est un peu plus que prévu et malheureux.
2. L'utilisateur ne peut pas VOIR les paramètres dans un ReportViewer de contrôle, sauf si elle est en mode à distance et d'accéder à un RLD rapport. Ainsi, vous avez besoin de faire des zones de texte, listes déroulantes, des boutons radio sur votre propre en dehors de la commande à passer. Certaines personnes aiment ce contrôle, je ne suis pas personnellement.
3. Tout ce que vous voulez faire avec l'entretien de rapports pour la distribution, vous devez construire vous-même. L'Emailing, les abonnements, les sauver. Désolé, vous avez besoin de le construire .NET ou encore de mettre en œuvre un proxy qui déjà n'est qu'à partir de ci-dessus, vous pourriez juste obtenir à l'aide de rapports hébergés.

Honnêtement, je voudrais à la fois à des fins différentes. Si je veux quelque chose pour aller aux analystes qu'ils utilisent tout le temps et de le tordre pour des graphiques, des diagrammes, des menus déroulants et des exportations vers Excel-je utiliser RDL et SSRS du site à faire tout le travail sur le terrain de la manipulation de l'e-mail distributions. Si je veux une application qui a un rapport de section et je sais que la demande est son propre module avec des règles et de la gouvernance-je utiliser un RDLC et ayant les paramètres les plus petits et d'être conduit par les décisions de l'utilisateur avant d'arriver à la partie de rapport de ce client, ils sont sur le site et puis ils ont l'habitude de simplement choisir un intervalle de temps ou de type et rien de plus. Donc généralement un rapport complexe je voudrais utiliser RDL et pour quelque chose de simple, je voudrais utiliser RDLC à mon humble avis.

J'espère que ça aide.

Answer 2

Q: Quelle est la différence entre la RDL et RDLC formats?

Un: RDL fichiers créés par le SQL Server 2005 version de Rapport Le concepteur. RDLC fichiers sont créés par le Visual Studio 2008 version Le Concepteur De Rapports.

RDL et RDLC formats ont le même XML schéma. Cependant, dans RDLC fichiers, certains les valeurs telles que le texte de la requête) sont peut être vide, ce qui signifie que ils ne sont pas immédiatement prêt à être publié sur un Serveur de Rapports. L' les valeurs manquantes peuvent être saisies par l'ouverture de la RDLC fichier à l'aide de SQL Server 2005 version de Rapport Le concepteur. (Vous devez le renommer .rdlc à .rdl en premier.)

RDL fichiers sont entièrement compatibles avec le contrôle ReportViewer de l'exécution. Cependant, RDL fichiers ne contiennent pas certains les informations que le moment de la conception de le contrôle ReportViewer dépend pour la génération automatique de code de liaison de données. Par la main de liaison de données, des fichiers RDL peut être utilisé dans la Contrôle ReportViewer. Nouveau! Voir aussi la RDL Viewer exemple de programme.

Notez que le contrôle ReportViewer ne contient pas logique pour connexion aux bases de données ou l'exécution de les requêtes. En séparant d'une telle logique, le ReportViewer a été faite compatible avec toutes les sources de données, y compris les non-base de données des sources de données. Cependant, cela signifie que lorsqu'un fichier RDL fichier est utilisé par le ReportViewer de contrôle, les informations liées à SQL dans le fichier RDL est tout simplement ignoré par le contrôle. Il est l'hôte l'application de la responsabilité de se connecter à des bases de données, exécuter des requêtes et de fournir des données à la ReportViewer de contrôle dans le formulaire de ADO.NET DataTables.

http://www.gotreportviewer.com/

Answer 3

J’ai toujours pensé que les différents entre RDL et RDLC RDL sont utilisé pour SQL Server Reporting Services et RDLC sont utilisés dans Visual Studio pour le rapport du côté client. La mise en œuvre et l’éditeur sont presque identiques. RDL est synonyme de langage de définition de rapport et côté Client RDLC Report Definition Language.

J’espère que cela aide.

Answer 4

De mon expérience, si vous avez besoin de haute performance (cela varie légèrement sur votre client spécifications) sur de grands rapports, aller avec rdlc. En outre, rdlc rapports vous donnent un ensemble très complet de contrôle sur vos données, vous pourriez être en mesure de vous épargner un gaspillage de voyages de base de données, etc. en utilisant côté client rapports. Sur le projet que je suis en train de travailler, un rapport critique nécessite environ 2 minutes pour se rendre du côté du serveur, et à peu près prend tout serveur de rapports à ce qu'il frappe pour l'époque. De commutation pour le rendu côté client, nous voyons des performances beaucoup plus proche de 20 à 40 secondes avec pas de charge sur le serveur de rapports et moins de bande passante utilisée car seuls les ensembles de données sont en cours de téléchargement.

Votre kilométrage peut varier, et je trouve rdlc ajouter de développement et de maintenance de la complexité, en particulier lorsque votre rapport a été conçu comme un serveur de rapports côté.

Answer 5

Certains de ces points ont été abordés ci-dessus, mais voici mes 2 cents pour VS2008 de l'environnement.

RDL (à Distance des rapports): Beaucoup mieux de l'expérience de développement, plus de flexibilité si vous avez besoin d'utiliser certaines fonctionnalités avancées, comme la planification, de rapports ad hoc, etc...

RDLC (rapports Locaux): un Meilleur contrôle sur les données avant de les envoyer au rapport (plus facile à valider ou de manipuler les données avant de les envoyer au rapport). Beaucoup plus facile de déploiement, pas besoin d'une instance de Reporting Services.

Un ÉNORME inconvénient avec les rapports locaux est une fuite de mémoire connus qui peuvent sérieusement affecter les performances si vos clients seront en cours d'exécution dans de nombreux rapports. C'est censé être abordé avec la nouvelle VS2010 version de la visionneuse de rapports.

Dans mon cas, depuis que nous avons une instance de Reporting Services disponibles, j'ai développer de nouveaux rapports de fichiers .rdl puis de les convertir en des rapports locaux (ce qui est facile) et de les déployer en tant que rapports locaux.