J'ai étudié le SSRS 2005/2008 ces dernières semaines et j'ai créé des rapports côté serveur. Pour une application, un collègue a suggéré que je regarde RDLC pour cette situation particulière. J'essaie maintenant de comprendre la principale différence entre RDL et RDLC.

La recherche de ces informations produit au mieux des informations fragmentées. J'ai appris que:

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

Mais je ne comprends toujours pas complètement la relation entre le fichier RDLC et les autres systèmes associés (le serveur de rapports, la base de données source, le client).

Afin de bien comprendre les fichiers RDLC, j'aimerais savoir en quoi leur utilisation diffère des fichiers RDL et dans quelle situation on choisirait RDLC plutôt que RDL. Les liens vers les ressources sont également les bienvenus.

Mettre à jour:

Un fil de discussion sur les forums ASP.NET traite de ce même problème. De là, j'ai acquis une meilleure compréhension de la question.

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

• Cela supprime le besoin d'une instance Reporting Services et supprime même le besoin de toute connexion à la base de données, mais:
• Il ajoute l'exigence selon laquelle les données nécessaires dans le rapport doivent être fournies manuellement.

Que ce soit un avantage ou un inconvénient dépend de l'application particulière.

Dans mon application, une instance de Reporting Services est quand même disponible et les données requises pour les rapports peuvent facilement être extraites d'une base de données. Y a-t-il une raison pour moi d'envisager RDLC, ou devrais-je simplement m'en tenir à RDL?

D'après mon expérience, il y a peu de choses à penser aux deux choses:

I. Les rapports RDL sont généralement des rapports HOSTED. Cela signifie que vous devez implémenter le serveur SSRS. Il s'agit d'une extension intégrée de Visual Studio à partir de SQL Server pour le langage de création de rapports. Lorsque vous installez SSRS, vous devriez avoir un module complémentaire appelé «Business Intelligence Development Studio», qui est beaucoup plus facile à utiliser avec les rapports que sans.

R apport

D éfinition

L angauge

Avantages des rapports RDL:

1. Vous pouvez héberger les rapports dans un environnement sur lequel des services sont exécutés pour vous.
2. Vous pouvez configurer la sécurité sur un élément ou un niveau d'héritage pour gérer la sécurité en tant que concept autonome
3. Vous pouvez configurer le service pour envoyer des e-mails (à condition que vous ayez un serveur SMTP auquel vous avez accès) et enregistrer des fichiers selon les horaires
4. Vous disposez d'une base de données généralement appelée «ReportServer», vous pouvez demander des informations sur les rapports une fois publiés.
5. Vous pouvez toujours accéder à ces rapports via «ReportViewer» dans une application client écrite en ASP.NET, WPF (avec un contrôle winform bleh!) Ou Winforms en .NET en utilisant «ProcessingMode.Remote».
6. Vous pouvez définir des paramètres qu'un utilisateur peut voir et utiliser pour gagner en flexibilité.
7. Vous pouvez configurer des parties d'un rapport à utiliser pour les chaînes de connexion en tant que «sources de données» ainsi qu'une requête SQL, XML ou d'autres ensembles de données en tant que «ensemble de données». Ces pièces et d'autres peuvent être stockées et configurées pour mettre en cache des données sur une base régulière.
8. Vous pouvez écrire des classes proxy .NET des services http: // / ReportServer / ReportingService2010 ou / ReportExecution2005. Vous pouvez ensuite créer vos propres méthodes dans .NET pour l'envoi par courrier électronique, l'enregistrement ou la manipulation des données SSRS à partir du service directement d'un serveur hébergeant des rapports SSRS dans le code. Exporter par programme le rapport SSRS à partir de SharePoint à l'aide de ReportService2010.asmx

Inconvénients:

1. SSRS est une sorte de wonkey par rapport à d'autres choses pour le faire rapidement. La plupart des gens sont déconcertés par la politique de sécurité et par la conception de rapports comme un «complément» à VS. SQL 2005 = VS BIDS 2005, SQL 2008 = VS BIDS 2008, SQL 2012 = VS BIDS 2010 (LOL).
2. Poursuivant sur 1 la politique pour les paramètres de sécurité IMHO sont idiots surcomplexe. Il y a la sécurité du serveur, la sécurité de la base de données et les rôles, deux paramètres de sécurité sur la page hébergée pour le service. La plupart des gens ne configurent qu'un administrateur qui ne peut pas entrer et se demandent pourquoi les autres utilisateurs ne le peuvent pas. La plainte ou la question la plus courante sur SSRS est liée à mon expérience.
3. Vous pouvez utiliser des «expressions» qui seront censées «améliorer» votre rapport. Souvent, vous en faites plus que quelques-uns et votre rapport est soumis à une analyse des performances.
4. Vous avez un certain nombre de choses que vous pouvez faire et exporter. SSRS n'a aucun survol des rapports que je connais sans un hack javascript.
5. La vitesse et les performances peuvent prendre un coup car la stupide configuration SSRS recycle le système et un premier rapport peut parfois prendre un certain temps juste pour charger le site. Vous pouvez contourner cela en le modifiant, mais j'ai trouvé que créer un service de maintien en vie fonctionne mieux.

II. Les rapports RDLC sont des rapports CONTENUS PAR LE CLIENT qui ne sont HÉBERGÉS PARTOUT. Le c supplémentaire dans le nom signifie «Client». Il s'agit généralement d'une extension du langage RDL destinée à être utilisée uniquement dans les applications clientes Visual Studio. Il existe dans Visual Studio lorsque vous ajoutez un élément de «rapport».

Avantages des rapports RDLC:

1. Vous pouvez connecter un service wcf beaucoup plus facilement à l'ensemble de données.
2. Vous avez plus de contrôle sur l'ensemble de données et pouvez utiliser des classes POCO remplies d'objets Entity Framework ou ADO.NET directement ainsi que des tables elles-mêmes. Vous pouvez singe avec les données pour l'optimiser avant de le lier au rapport.
3. Vous pouvez personnaliser davantage l'apparence avec des modules complémentaires directement dans le code.

Inconvénients:

1. Vous devez gérer les paramètres vous-même et bien que vous puissiez implémenter des méthodes wrapper pour aider les démarches, c'est un peu plus que prévu et malheureux.
2. L'utilisateur ne peut pas VOIR les paramètres dans un contrôle 'ReportViewer' sauf s'il est en mode distant et accède à un rapport RLD. Ainsi, vous devez créer vous-même des zones de texte, des listes déroulantes, des boutons radio en dehors du contrôle pour y passer. Certaines personnes aiment ce contrôle supplémentaire, je ne le fais pas personnellement.
3. Tout ce que vous voulez faire avec la maintenance des rapports pour la distribution, vous devez le créer vous-même. Emailing, abonnements, sauvegarde. Désolé, vous devez créer cela dans .NET ou bien implémenter un proxy qui le fait déjà par le haut, vous pourriez simplement obtenir des rapports hébergés.

Honnêtement, j'aime les deux à des fins différentes. Si je veux que quelque chose soit envoyé aux analystes qu'ils utilisent tout le temps et qu'ils modifient les graphiques, les graphiques, les analyses et les exportations vers Excel, j'utilise RDL et je demande au site de SSRS de faire tout le travail de gestion des distributions de courrier électronique. Si je veux une application qui a une section de rapport et que je sais que l'application est son propre module avec des règles et une gouvernance, j'utilise un RDLC et j'ai des paramètres plus petits et je suis guidé par les décisions que l'utilisateur a prises avant d'accéder au rapport. client, ils sont sur et site, puis ils choisissent généralement juste une période ou un type et rien de plus. Donc généralement un rapport complexe j'utiliserais RDL et pour quelque chose de simple j'utiliserais RDLC IMHO.

J'espère que cela aide.

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

R: Les fichiers RDL sont créés par la version SQL Server 2005 de Report Designer. Les fichiers RDLC sont créés par la version Visual Studio 2008 de Report Designer.

Les formats RDL et RDLC ont le même schéma XML. Cependant, dans les fichiers RDLC, certaines valeurs (telles que le texte de la requête) peuvent être vides, ce qui signifie qu'elles ne sont pas immédiatement prêtes à être publiées sur un serveur de rapports. Les valeurs manquantes peuvent être saisies en ouvrant le fichier RDLC à l'aide de la version SQL Server 2005 de Report Designer. (Vous devez d'abord renommer .rdlc en .rdl.)

Les fichiers RDL sont entièrement compatibles avec le runtime du contrôle ReportViewer. Toutefois, les fichiers RDL ne contiennent pas certaines informations dont dépend la conception du contrôle ReportViewer pour générer automatiquement le code de liaison de données. En liant manuellement les données, les fichiers RDL peuvent être utilisés dans le contrôle ReportViewer. Nouveau! Voir également l'exemple de programme RDL Viewer.

Notez que le contrôle ReportViewer ne contient aucune logique pour se connecter aux bases de données ou exécuter des requêtes. En séparant cette logique, le ReportViewer a été rendu compatible avec toutes les sources de données, y compris les sources de données hors base de données. Toutefois, cela signifie que lorsqu'un fichier RDL est utilisé par le contrôle ReportViewer, les informations relatives à SQL dans le fichier RDL sont simplement ignorées par le contrôle. Il est de la responsabilité de l'application hôte de se connecter aux bases de données, d'exécuter des requêtes et de fournir des données au contrôle ReportViewer sous la forme de ADO.NET DataTables.

http://www.gotreportviewer.com/

J'ai toujours pensé que la différence entre RDL et RDLC est que RDL est utilisé pour SQL Server Reporting Services et RDLC est utilisé dans Visual Studio pour les rapports côté client. L'implémentation et l'éditeur sont presque identiques. RDL signifie Report Defintion Languageet RDLC Report Definition Language Client-side .

J'espère que cela aide.

D'après mon expérience, si vous avez besoin de hautes performances (cela dépend légèrement des spécifications de votre client) sur des rapports volumineux, optez pour rdlc. De plus, les rapports rdlc vous donnent une gamme très complète de contrôle sur vos données, vous pourrez peut-être vous épargner des voyages de base de données inutiles, etc. en utilisant des rapports côté client. Sur le projet sur lequel je travaille actuellement, un rapport critique nécessite environ 2 minutes pour être rendu côté serveur et supprime à peu près le serveur de rapports qu'il frappe pendant cette période. En le basculant vers le rendu côté client, nous voyons des performances beaucoup plus proches de 20 à 40 secondes sans 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 que le développement et la maintenance de rdlc sont complexes, en particulier lorsque votre rapport a été conçu comme un rapport côté serveur.

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

RDL (rapports à distance): bien meilleure expérience de développement, plus de flexibilité si vous avez besoin d'utiliser certaines fonctionnalités avancées telles que la planification, les rapports ad hoc, etc.

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

Une ÉNORME mise en garde avec les rapports locaux est une fuite de mémoire connue qui peut gravement affecter les performances si vos clients exécutent de nombreux rapports volumineux. Ce problème est censé être résolu avec la nouvelle version VS2010 de la visionneuse de rapports.

Dans mon cas, puisque nous avons une instance de Reporting Services disponible, je développe de nouveaux rapports sous forme de RDL, puis je les convertis en rapports locaux (ce qui est facile) et les déploie en tant que rapports locaux.

Si vous disposez d'une infrastructure de services de reporting, utilisez-la. Vous trouverez que le développement RDL est un peu plus agréable. Vous pouvez prévisualiser le rapport, configurer facilement les paramètres, etc.

Bien que je penche actuellement vers RDL car il semble plus flexible et plus facile à gérer, RDLC a un avantage en ce sens qu'il semble simplifier vos licences. Étant donné que RDLC n'a pas besoin d'une instance Reporting Services, vous n'avez pas besoin d'une licence Reporting Services pour l'utiliser.

Je ne sais pas si cela s'applique toujours avec les nouvelles versions de SQL Server, mais à un moment donné, si vous avez choisi de placer les instances SQL Server Database et Reporting Services sur deux machines distinctes, vous deviez avoir deux licences SQL Server distinctes:
http://social.msdn.microsoft.com/forums/en-US/sqlgetstarted/thread/82dd5acd-9427-4f64-aea6-511f09aac406/

Vous pouvez Bing pour d'autres blogs et articles similaires concernant les licences Reporting Services.

Pour VS2008, je pense que RDL vous offre de meilleures fonctionnalités d'édition que RDLC. Par exemple, je peux changer le gras sur une quantité sélectionnée de texte dans une zone de texte avec RDL, alors que dans RDLC, ce n'est pas possible.

RDL: abcd efgh ijklmnop

RDLC: abcd efgh ijklmnop -ou- abcd efgh ijklmnop (sont vos seules options)

Ceci est dû au fait que RDLC utilise un espace de noms / formatage antérieur de 2005, tandis que RDL utilise 2008. Cela changera cependant avec VS2010

Si nous avons moins de rapports qui sont moins complexes et consommés par les pages Web asp.net. Il est préférable d'utiliser rdlc, car nous pouvons éviter de maintenir les rapports sur l'instance RS. mais nous devons récupérer les données de DB manuellement et les lier à rdlc.

Inconvénients: concevoir rdlc dans un studio visuel est peu difficile par rapport au concepteur SSrs.

Pro: La maintenance est facile. lors de l'exportation du rapport à partir de notre page, nous avons observé ce gain de performances par rapport aux rapports côté serveur.

si vous souhaitez utiliser le rapport dans asp.net, utilisez .rdl si vous souhaitez utiliser / view dans le générateur de rapports / serveur de rapports, puis utilisez .rdlc simplement en convertissant le format manuellement, cela fonctionne