He estado estudiando SSRS 2005/2008 en las últimas semanas y he creado algunos informes del lado del servidor. Para alguna aplicación, un colega sugirió que investigara RDLC para esa situación en particular. Ahora estoy tratando de entender la principal diferencia entre RDL y RDLC.

La búsqueda de esta información produce información fragmentada en el mejor de los casos. He aprendido que:

• Los informes RDLC no almacenan información sobre cómo obtener datos.
• Los informes RDLC se pueden ejecutar directamente mediante el control ReportViewer.

Pero todavía no entiendo completamente la relación entre el archivo RDLC y los otros sistemas relacionados (el servidor de informes, la base de datos de origen, el cliente).

Para comprender bien los archivos RDLC, me gustaría saber en qué difiere su uso de los archivos RDL y en qué situación se elegiría RDLC sobre RDL. Los enlaces a recursos también son bienvenidos.

Actualizar:

Un hilo en los foros de ASP.NET analiza este mismo tema. Gracias a él, he obtenido una mejor comprensión del tema.

Una característica de RDLC es que se puede ejecutar completamente en el lado del cliente en el control ReportViewer.

• Esto elimina la necesidad de una instancia de Reporting Services e incluso elimina la necesidad de cualquier conexión a la base de datos, pero:
• Agrega el requisito de que los datos que se necesitan en el informe deben proporcionarse manualmente.

Si esto es una ventaja o una desventaja depende de la aplicación particular.

En mi aplicación, una instancia de Reporting Services está disponible de todos modos y los datos necesarios para los informes se pueden extraer fácilmente de una base de datos. ¿Me queda alguna razón para considerar RDLC, o debería simplemente seguir con RDL?

Según mi experiencia, hay pocas cosas en las que pensar en ambas cosas:

I. Los informes RDL son informes HOSTED generalmente. Esto significa que debe implementar el servidor SSRS. Son una extensión integrada de Visual Studio de SQL Server para el lenguaje de informes. Cuando instale SSRS, debería tener un complemento llamado 'Business Intelligence Development Studio', que es mucho más fácil de trabajar con los informes que sin él.

R nforme

D efinición

L angauge

Beneficios de los informes RDL:

1. Puede alojar los informes en un entorno que tenga servicios ejecutándose para usted.
2. Puede configurar la seguridad en un elemento o heredar el nivel para manejar la seguridad como un concepto independiente
3. Puede configurar el servicio para enviar correos electrónicos (siempre que tenga un servidor SMTP al que tenga acceso) y guardar archivos en horarios
4. Tiene una base de datos generalmente llamada 'ReportServer' que puede consultar para obtener información sobre los informes una vez publicados.
5. Puede acceder a estos informes aún a través de 'ReportViewer' en una aplicación cliente escrita en ASP.NET, WPF (con un control de winform bleh!), O Winforms en .NET usando 'ProcessingMode.Remote'.
6. Puede establecer parámetros que un usuario puede ver y usar para ganar más flexibilidad.
7. Puede configurar partes de un informe para que se utilicen para cadenas de conexión como 'Fuentes de datos', así como una consulta SQL, XML u otros conjuntos de datos como un 'Conjunto de datos'. Estas partes y otras se pueden almacenar y configurar para almacenar datos en caché de forma regular.
8. Puede escribir clases de proxy .NET de los servicios http: // / ReportServer / ReportingService2010 o / ReportExecution2005. Luego, puede crear sus PROPIOS métodos en .NET para enviar por correo electrónico, guardar o manipular datos SSRS desde el servicio directamente de un servidor que aloja informes SSRS en código. Exportar mediante programación el informe SSRS desde sharepoint usando ReportService2010.asmx

Desventajas:

1. SSRS es un poco complicado en comparación con otras cosas sobre cómo hacerlo rápido. La mayoría de las personas se confunden con la política de seguridad y el diseño de informes como un "complemento" de VS. SQL 2005 = VS BIDS 2005, SQL 2008 = VS BIDS 2008, SQL 2012 = VS BIDS 2010 (LOL).
2. Continuando en 1, la política para la configuración de seguridad en mi humilde opinión es idiotamente demasiado compleja. Hay seguridad de servidor, seguridad de base de datos y roles, dos configuraciones de seguridad en la página alojada para el servicio. La mayoría de las personas solo configura un administrador que no puede ingresar y se pregunta por qué otros usuarios no pueden. La queja o pregunta más común sobre SSRS está relacionada con la entrada en general de mi experiencia.
3. Puede utilizar "expresiones" que supuestamente "mejorarán" su informe. A menudo, hace más de unas pocas y su informe tiene un rendimiento lento.
4. Tiene una cantidad determinada de cosas que puede hacer y exportar. SSRS no tiene ningún control sobre los informes que conozco sin un hack de JavaScript.
5. La velocidad y el rendimiento pueden verse afectados, ya que la estúpida configuración de SSRS recicla el sistema y un primer informe puede llevar un tiempo, a veces, solo cargar el sitio. Puede evitar esto modificándolo, pero he descubierto que hacer un servicio de mantener vivo funciona mejor.

II. Los informes RDLC son informes CONTENIDOS DEL CLIENTE que NO ESTÁN ALOJADOS EN NINGÚN LUGAR. La c adicional en el nombre significa "Cliente". Por lo general, esta es una extensión del lenguaje RDL diseñada para usarse solo en aplicaciones cliente de Visual Studio. Existe en Visual Studio cuando agrega un elemento de "informes".

Beneficios de los informes RDLC:

1. Puede conectar un servicio de wcf mucho más fácilmente al conjunto de datos.
2. Tiene más control sobre el conjunto de datos y puede usar clases POCO llenas de objetos Entity framework o ADO.NET directamente, así como las propias tablas. Puede utilizar los datos para optimizarlos antes de vincularlos al informe.
3. Puede personalizar más el aspecto con complementos directamente en el código subyacente.

Desventajas:

1. Debe manejar los parámetros por su cuenta y, si bien puede implementar métodos de envoltura para ayudar, el trabajo preliminar es un poco más de lo esperado y desafortunado.
2. El usuario no puede VER los parámetros en un control 'ReportViewer' a menos que esté en modo remoto y accediendo a un informe RLD. Por lo tanto, debe crear cuadros de texto, menús desplegables, botones de radio por su cuenta fuera del control para pasarlos. A algunas personas les gusta este control añadido, yo personalmente no.
3. Todo lo que desee hacer con el mantenimiento de los informes para su distribución debe crearlo usted mismo. Envío de correos electrónicos, suscripciones, ahorro. Lo sentimos, necesita construir eso en .NET o implementar un proxy que ya lo haga desde arriba, podría estar usando informes alojados.

Sinceramente, me gustan ambos para diferentes propósitos. Si quiero enviar algo a los analistas que usan todo el tiempo y modificar para gráficos, tablas, desgloses y exportaciones a Excel, uso RDL y solo tengo que hacer que el sitio de SSRS haga todo el trabajo preliminar para manejar las distribuciones de correo electrónico. Si quiero una aplicación que tenga una sección de informe y sé que la aplicación es su propio módulo con reglas y gobernanza, uso un RDLC y los parámetros son más pequeños y me guían por las decisiones que tomó el usuario antes de llegar a la parte del informe de qué cliente están en un sitio y luego, por lo general, solo eligen un marco de tiempo o tipo y nada más. Entonces, en general, un informe complejo usaría RDL y para algo simple usaría RDLC en mi humilde opinión.

Espero que eso ayude.

P: ¿Cuál es la diferencia entre los formatos RDL y RDLC?

R: Los archivos RDL son creados por la versión SQL Server 2005 del Diseñador de informes. Los archivos RDLC son creados por la versión Visual Studio 2008 de Report Designer.

Los formatos RDL y RDLC tienen el mismo esquema XML. Sin embargo, en los archivos RDLC, algunos valores (como el texto de la consulta) pueden estar vacíos, lo que significa que no están listos inmediatamente para ser publicados en un servidor de informes. Los valores faltantes se pueden ingresar abriendo el archivo RDLC usando la versión SQL Server 2005 del Diseñador de informes. (Primero debe cambiar el nombre de .rdlc a .rdl).

Los archivos RDL son totalmente compatibles con el tiempo de ejecución del control ReportViewer. Sin embargo, los archivos RDL no contienen información de la que dependa el tiempo de diseño del control ReportViewer para generar automáticamente el código de enlace de datos. Al vincular datos manualmente, los archivos RDL se pueden utilizar en el control ReportViewer. ¡Nuevo! Consulte también el programa de muestra RDL Viewer.

Tenga en cuenta que el control ReportViewer no contiene ninguna lógica para conectarse a bases de datos o ejecutar consultas. Al separar dicha lógica, ReportViewer se ha hecho compatible con todas las fuentes de datos, incluidas las fuentes de datos que no son de base de datos. Sin embargo, esto significa que cuando el control ReportViewer utiliza un archivo RDL, el control simplemente ignora la información relacionada con SQL en el archivo RDL. Es responsabilidad de la aplicación host conectarse a bases de datos, ejecutar consultas y suministrar datos al control ReportViewer en forma de ADO.NET DataTables.

http://www.gotreportviewer.com/

Siempre he pensado que la diferencia entre RDL y RDLC es que RDL se usa para SQL Server Reporting Services y RDLC se usa en Visual Studio para informes del lado del cliente. La implementación y el editor son casi idénticos. RDL significa Report Defintion Languagey RDLC Report Definition Language Client-side .

Espero que eso ayude.

Según mi experiencia, si necesita un alto rendimiento (esto depende ligeramente de las especificaciones de su cliente) en informes grandes, vaya con rdlc. Además, los informes rdlc le brindan un rango muy completo de control sobre sus datos, es posible que pueda ahorrarse viajes desperdiciados en la base de datos, etc., utilizando informes del lado del cliente. En el proyecto en el que estoy trabajando actualmente, un informe crítico requiere aproximadamente 2 minutos para renderizarse en el lado del servidor, y prácticamente elimina cualquier servidor de informes al que llegue durante ese tiempo. Al cambiarlo a la representación del lado del cliente, vemos un rendimiento mucho más cercano a 20-40 segundos sin carga en el servidor de informes y menos ancho de banda utilizado porque solo se descargan los conjuntos de datos.

Su kilometraje puede variar, y encuentro que rdlc agrega complejidad de desarrollo y mantenimiento, especialmente cuando su informe ha sido diseñado como un informe del lado del servidor.

Algunos de estos puntos se han abordado anteriormente, pero aquí están mis 2 centavos para el entorno VS2008.

RDL (informes remotos): experiencia de desarrollo mucho mejor, más flexibilidad si necesita utilizar algunas funciones avanzadas como programación, informes ad-hoc, etc.

RDLC (Informes locales): mejor control sobre los datos antes de enviarlos al informe (más fácil de validar o manipular los datos antes de enviarlos al informe). Implementación mucho más sencilla, sin necesidad de una instancia de Reporting Services.

Una GRAN advertencia con los informes locales es una fuga de memoria conocida que puede afectar gravemente al rendimiento si sus clientes ejecutarán numerosos informes grandes. Se supone que esto se solucionará con la nueva versión VS2010 del visor de informes.

En mi caso, dado que tenemos una instancia de Reporting Services disponible, desarrollo nuevos informes como RDL y luego los convierto en informes locales (lo cual es fácil) y los implemento como informes locales.

Si tiene una infraestructura de servicios de informes disponible, úsela. Descubrirá que el desarrollo de RDL es un poco más agradable. Puede obtener una vista previa del informe, configurar parámetros fácilmente, etc.

Si bien actualmente me inclino por RDL porque parece más flexible y fácil de administrar, RDLC tiene la ventaja de que parece simplificar su licencia. Dado que RDLC no necesita una instancia de Reporting Services, no necesitará una licencia de Reporting Services para usarlo.

No estoy seguro de si esto todavía se aplica a las versiones más recientes de SQL Server, pero en un momento dado, si eligió colocar las instancias de SQL Server Database y Reporting Services en dos máquinas separadas, se le pidió que tuviera dos licencias de SQL Server separadas:
http://social.msdn.microsoft.com/forums/en-US/sqlgetstarted/thread/82dd5acd-9427-4f64-aea6-511f09aac406/

Puede Bing para otros blogs y publicaciones similares sobre licencias de Reporting Services.

Para VS2008, creo que RDL le ofrece mejores funciones de edición que RDLC. Por ejemplo, puedo cambiar el Negrita en una cantidad seleccionada de texto en un cuadro de texto con RDL, mientras que en RDLC no es posible.

RDL: abcd efgh ijklmnop

RDLC: abcd efgh ijklmnop -o- abcd efgh ijklmnop (son sus únicas opciones)

Esto se debe a que RDLC usa un espacio de nombres / formato anterior de 2005, mientras que RDL usa 2008. Sin embargo, esto cambiará con VS2010

Si tenemos un menor número de informes que son menos complejos y consumidos por las páginas web de asp.net. Es mejor ir con rdlc, la razón es que podemos evitar mantener informes en la instancia de RS. pero tenemos que recuperar los datos de la base de datos manualmente y vincularlos a rdlc.

Contras: diseñar rdlc en Visual Studio es un poco difícil en comparación con el diseñador SSrs.

Ventaja: el mantenimiento es sencillo. al exportar el informe de nuestra página, observó que el rendimiento mejora en comparación con los informes del lado del servidor.

si desea usar el informe en asp.net, use .rdl si desea usar / ver en el generador de informes / servidor de informes, luego use .rdlc simplemente convirtiendo el formato manualmente, funciona