reporting-services - sqlserver - la definición del informe puede que se haya creado con una versión posterior de reporting services

Cuándo usar RDLC sobre informes RDL? (10)

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 de Report Designer. 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 consulta) pueden estar vacíos, lo que significa que no están inmediatamente listos para publicarse en un servidor de informes. Los valores faltantes pueden ingresarse abriendo el archivo RDLC utilizando la versión de SQL Server 2005 de Report Designer. (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 depende el tiempo de diseño del control ReportViewer para generar código de enlace de datos automáticamente. Al vincular datos manualmente, los archivos RDL se pueden usar en el control ReportViewer. ¡Nuevo! Ver también el programa de ejemplo 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 esa 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 tablas de datos ADO.NET.

http://www.gotreportviewer.com/

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

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

Los informes de RDLC no almacenan información sobre cómo obtener datos.
Los informes RDLC se pueden ejecutar directamente con 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).

Con el fin de obtener una buena comprensión de los archivos RDLC, me gustaría saber cómo su uso difiere de los archivos RDL y en qué situación uno elegiría RDLC sobre RDL. Los enlaces a los recursos también son bienvenidos.

Actualizar:

Un hilo en los foros de ASP.NET discute este mismo problema. A partir de ello, obtuve un mejor entendimiento sobre el tema.

Una característica de RDLC es que puede ejecutarse 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 de base de datos, pero:
Agrega el requisito de que los datos que se necesitan en el informe se deben proporcionar de forma manual.

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 pueden extraerse fácilmente de una base de datos. ¿Hay algún motivo para considerar RDLC, o debería simplemente seguir con RDL?

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

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

RDLC (informes locales): Mejor control de 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 pérdida de memoria conocida que puede afectar gravemente el rendimiento si sus clientes ejecutarán numerosos informes grandes. Se supone que esto debe abordarse 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 despliego como informes locales.

Desde mi experiencia, hay pocas cosas en las que pensar sobre ambas cosas:

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

Informe

D efinition

L angauge

Beneficios de los informes RDL:

Puede alojar los informes en un entorno que tenga servicios que se ejecutan para usted en ellos.
Puede configurar la seguridad de un elemento o nivel heredado para manejar la seguridad como un concepto independiente
Puede configurar el servicio para enviar correos electrónicos (siempre que tenga un servidor SMTP al que tenga acceso) y guardar archivos en horarios
Usted tiene una base de datos generalmente llamada ''ReportServer'' que puede consultar para obtener información sobre los informes una vez publicados.
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 winform bleh!), O Winforms en .NET usando ''ProcessingMode.Remote''.
Puede establecer los parámetros que un usuario puede ver y usar para obtener más flexibilidad.
Puede configurar partes de un informe que se utilizarán para cadenas de conexión como ''Fuentes de datos'', así como una consulta sql, xml u otros conjuntos de datos como ''Dataset''. Estas partes y otras se pueden almacenar y configurar para almacenar en caché los datos de forma regular.
Puede escribir clases de proxy .NET de los servicios http: // / ReportServer / ReportingService2010 o / ReportExecution2005. A continuación, puede crear sus propios métodos en .NET para enviar por correo electrónico, guardar o manipular los datos de SSRS del servicio directamente de un servidor que aloja los informes de SSRS en el código. Exporte programáticamente SSRS desde sharepoint utilizando ReportService2010.asmx

Desventajas:

SSRS es una especie de llave en mano comparado con otras cosas al levantarse rápido. La mayoría de las personas se confunde con la política de seguridad y diseña informes como un "complemento" a VS. SQL 2005 = VS BIDS 2005, SQL 2008 = VS BIDS 2008, SQL 2012 = VS BIDS 2010 (LOL).
Continuando el 1, la política de configuración de seguridad en mi humilde opinión es idiotamente demasiado compleja. Hay seguridad del servidor, seguridad de la base de datos y roles, dos configuraciones de seguridad en la página alojada para el servicio. La mayoría de las personas solo configuran un administrador que no puede entrar y se preguntan por qué otros usuarios no pueden hacerlo. La queja o pregunta más común sobre SSRS se relaciona con el hecho de entrar en general a partir de mi experiencia.
Puede usar ''expresiones'' que supuestamente ''mejorarán'' su informe. A menudo haces más que unos pocos y tu informe se ralentiza en rendimiento.
Tiene una cantidad establecida de cosas que puede hacer y exportar a. SSRS no se mueve sobre los informes que conozco sin un javascript hackeo.
La velocidad y el rendimiento pueden ser un éxito ya que las estúpidas configuraciones SSRS reciclan el sistema y un primer informe puede tardar un tiempo en cargar el sitio. Puedes evitar esto al modificarlo, pero he encontrado hacer un servicio de mantenimiento para que funcione mejor.

II. Los informes RDLC son informes CONTENIDOS POR EL CLIENTE que NO SE ENCUENTRAN EN NINGÚN LUGAR. La c adicional en el nombre significa ''Cliente''. En general, esta es una extensión del lenguaje RDL destinado para su uso exclusivo en las aplicaciones de cliente de Visual Studio. Existe en Visual Studio cuando agrega un elemento de "informe".

Beneficios de los informes RDLC:

Puede conectar un servicio wcf mucho más fácil para el conjunto de datos.
Usted tiene más control sobre el conjunto de datos y puede usar las clases POCO llenas con objetos del marco Entity o ADO.NET directamente, así como las tablas mismas. Puede simular los datos para optimizarlos antes de vincularlos al informe.
Puede personalizar el aspecto más con agregar directamente en el código detrás.

Desventajas:

Debe manejar los parámetros por su cuenta y, a la vez, puede implementar los métodos de contenedor para ayudar a que el trabajo de campo sea un poco más de lo esperado y desafortunado.
El usuario no puede VER los parámetros en un control ''ReportViewer'' a menos que esté en modo remoto y acceda a un informe RLD. Por lo tanto, necesita hacer cuadros de texto, menús desplegables, botones de radio propios fuera del control para pasar a él. A algunas personas les gusta este control agregado, yo no personalmente.
Cualquier cosa que desee hacer con el mantenimiento de los informes para la distribución que necesita construir usted mismo. Envío por correo electrónico, suscripciones, ahorro. Lamentamos que necesite compilarlo en .NET o bien implementar un proxy que ya lo haga desde arriba, solo podría estar usando informes hospedados.

Honestamente me gustan ambos para diferentes propósitos. Si quiero que los analistas utilicen todo el tiempo y modifiquen gráficos, tablas, profundizaciones y exportaciones a Excel, utilizo RDL y simplemente hago que el sitio de SSRS haga todo el trabajo de manejo de 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 e impulsados por las decisiones que tomó el usuario antes de llegar al informe. cliente en el que están y en el sitio y, por lo general, solo eligen un marco de tiempo o tipo y nada más. Por lo general, un informe complejo que usaría RDL y por algo simple, usaría RDLC en mi humilde opinión.

Espero que eso ayude.

Desde mi experiencia, si necesita un alto rendimiento (esto depende un poco de las especificaciones de su cliente) en informes grandes, vaya con rdlc. Además, los informes rdlc le brindan un control muy completo sobre sus datos, puede ahorrar viajes de bases de datos desperdiciados, etc. mediante el uso de informes del lado del cliente. En el proyecto en el que estoy trabajando actualmente, un informe crítico requiere alrededor de 2 minutos para procesarlo en el lado del servidor, y prácticamente elimina el servidor de informes al que llegue en ese momento. Al cambiarlo a la representación del lado del cliente, vemos el rendimiento mucho más cerca de 20-40 segundos sin carga en el servidor de informes y menos ancho de banda utilizado porque solo se están descargando los conjuntos de datos.

Su millaje 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.

Para VS2008, creo que RDL le brinda mejores funciones de edición que RDLC. Por ejemplo, puedo cambiar la 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 -or- abcd efgh ijklmnop (son sus únicas opciones)

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

Si bien actualmente me inclino por RDL porque parece ser 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 usarla.

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

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

Si tenemos menos informes que sean menos complejos y consumidos por las páginas web de asp.net. Es mejor ir con rdlc, porque es posible evitar los informes de mantenimiento en la instancia de RS. pero tenemos que buscar los datos de DB manualmente y vincularlos a rdlc.

Contras: diseñar rdlc en visual studio es un poco difícil comparado con el diseñador de SSrs.

Pro: el mantenimiento es fácil. al exportar el informe desde nuestra página, observamos que la ganancia de rendimiento se compara con los informes del lado del servidor.

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

Siempre he pensado que lo diferente entre RDL y RDLC es que RDL se usa para SQL Server Reporting Services y RDLC se usan en Visual Studio para informes de clientes. La implementación y el editor son casi idénticos. RDL significa Idioma de definición de informe y Lenguaje de definición de informe RDLC del lado del cliente.

Espero que eso ayude.

si desea utilizar el informe en asp.net, utilice .rdl si desea usar / ver en el generador de informes / servidor de informes y luego use .rdlc con solo convertir el formato manualmente.