crystal-reports - tutorial - crystal reports visual studio
Crystal Reports.Net Guidance (9)
Hemos estado usando .Net y Visual Studio durante los últimos seis años, y desde el principio desarrollamos varias aplicaciones de informes basadas en web que utilizan la versión .Net de Crystal Reports que se incluyó con Visual Studio. No estoy impresionado con ese producto: parece increíblemente difícil y complicado de usar. Tuvimos que hacer cambios de seguridad, instalar varios programas adicionales, etc.
Ahora, nos estamos moviendo a VS2008 y la versión 3.5 del framework .Net, y ha llegado el momento de redesarrollar aplicaciones antiguas. Nuestros desarrolladores de Crystal .Net han desaparecido hace mucho tiempo y me enfrento a una decisión: ¿nos quedamos con Crystal o nos mudamos a otra cosa? Tenemos la versión "completa" de Crystal Reports XI a nuestra disposición.
Producimos versiones en PDF de datos extraídos de diversas bases de datos. Algunas aplicaciones usan el visor de informes incorporado, pero esto parece redundante con la flexibilidad de las vistas de cuadrícula. Todavía tenemos que producir PDF imprimibles en la grilla o en un formato Excel descargable.
- ¿Vale la pena continuar con Crystal Reports .Net o deberíamos averiguar cómo usar la versión XI?
- Alternativamente, ¿existe una forma simple y económica de generar informes PDF sin utilizar Crystal?
Recomendaría i-net Clear Reports (solía ser i-net Crystal-Clear). Puede leer sus archivos * .rpt existentes. Tiene una API mejor y más fácil de usar (que admito que no dice mucho ...).
Al igual que usted, he tenido malas experiencias con Crystal Reports, y mi instinto es publicar "evitarlo a toda costa" en mayúsculas con muchos signos de admiración. Sin embargo, he tenido mi siesta de la tarde de hoy, así que voy a publicar como un adulto.
Si todo lo que estás buscando hacer es pdf -ize (sí, es una palabra real, ¡maldita sea!) Entonces podrías mirar algunos de los widgets PDF como ABCPDF y similares. Es relativamente fácil insertar una página web bien formateada en un documento PDF y terminar con ella.
Sin embargo, si necesita un formato de informe ajustado, considere seguir con los informes de Crystal: tiene una gran base de inversión y conocimiento en la tecnología. O, alternativamente, podría cambiar a los servicios de informes ActiveReports o SQL Server.
Supongo que el análisis de costo / beneficio es el costo de volver a capacitar a su equipo de desarrollo e invertir en las nuevas tecnologías.
Aléjese de CR: simplemente obtenga un buen generador de PDF y motor de Excel para .NET, y alimente a aquellos que usan su propio código de base de datos. Puede utilizar todas las potentes características .NET, incluido LINQ, sin tener que luchar con el tiempo de ejecución de Crystal Reports y su lamentablemente inadecuada documentación y soporte.
He usado ActiveReports desde DataDynamics y Crystal Reports. De estos dos, recomendaría ActiveReports por encima de Crystal en función de la facilidad de uso y, lo que es más importante, del mantenimiento futuro.
Puedo sugerir que el marco de trabajo integrado de Microsoft funciona adecuadamente. Puede hacer informes locales o informes basados en el servidor MS SQL. Hay un control de cliente que muestra informes y puede exportar a formatos como PDF y Excel. Visual Studio puede manejar el diseño del informe para la pila.
En cuanto a si es mejor que Crystal Reports, yo diría que verifíquelo y vea si le gusta más o peor. He trabajado con el Visor de informes de Microsoft más que Crystal Reports, pero ambos parecen ser bastante similares. De manera manual, Crystal Reports parece ser una herramienta de informes más avanzada pero más complicada.
No estoy seguro acerca de cómo utilizar la infraestructura de Microsoft Report Viewer fuera de Visual Studio. Si está usando Visual Studio, todo debe estar disponible allí y puede seguir las instrucciones de ayuda en línea para implementar las piezas de sus servidores en sus servidores.
Tengo experiencia en informes en Crystal Reports (probando la versión lite incluida con Visual Studio), ActiveReports desde DataDynamics (4 años, versión completa), Reporting desde Telerik (probando versión de prueba) y XtraReports desde DevExpress (último año).
Creo que (y no solo a mí :)), CrystalReports es la herramienta más ineficiente (productividad del desarrollador) de estas herramientas. Los DataDynamics son mucho, mucho mejores, bud es littlebit buggy :(. El año pasado decidimos cambiar el conjunto de informes: hemos elegido un XtraReports (con código fuente), y estoy totalmente contento. El precio es pequeño, no hay errores (hasta ahora :)), maravilloso apoyo, y (lo más importante) la productividad creció mucho.
Te recomiendo las herramientas de informes de DevExpress o Telerik.
Usamos Crystal en nuestra tienda también. Actualmente estamos en 8.5, lo cual es muy antiguo y ya no es compatible con SAP. Intentamos actualizar a CRXI recientemente, lo que implicó una API completamente nueva. Tuvimos que aguantar el esfuerzo debido a otras prioridades. Mientras trabajaba en la actualización, encontré soporte para CRXI en una serie de foros. Buscalo en Google.
Creo que puedes encontrar una forma económica de generar archivos PDF sin utilizar Crystal. Creo que Adobe le da la parte de la creación de forma gratuita. Yo visitaría su sitio y lo investigaría.
Recomendaría quedarme con Crystal solo si tuviera muchos informes que ya usaran esa tecnología.
Sal de Crystal Reports . Ellos son pobres.
Consulte SQL Reporting Services . Funciona muy bien con .NET. Pruébalo. Hay una curva de aprendizaje, pero ¿cuándo no?
OMI, debe considerar otros criterios también, como:
- Costo del software
- Integración con sus aplicaciones .NET
- API y flexibilidad programática (Todo dicho y hecho, siempre están las "personalizaciones" y la personalización. Para tales escenarios, los desarrolladores eventualmente recurren a las soluciones programáticas en comparación con las soluciones de fábrica).
Ahora, en mi experiencia (habiendo usado Crystal Reports y SSRS (2005/2008), aunque Crystal Reports viene con un conjunto amigable de API, falla en muchos criterios básicos y los desarrolladores terminan peleando con el software. mi experiencia con SSRS donde los desarrolladores se sienten mucho más cómodos. Para empezar, usa XML ampliamente y la provisión para usar conjuntos de códigos personalizados tampoco daña.
- Creo que lo harías donde estoy llegando ---
"Considere y evalúe SSRS *. Si duda al principio, haga una prueba de concepto y pruebe sus requisitos. Tengo la sensación de que estará satisfecho con lo que ve.
- especialmente teniendo en cuenta su requisito de usar formato PDF.
- Los desarrolladores, especialmente los especialistas de MSFT, se lo agradecerán
- Aproveche la representación programática de los informes (aunque suena sofisticado, créame, no es más que el manejo de una llamada API
Por ejemplo: public Byte [] Render (string Report, string Format , string HistoryID, string DeviceInfo, [Namespace] .ParameterValue [] Parameters, [Namespace] .DataSourceCredentials [] Credentials, string ShowHideToggle, out string Encoding, out string MimeType, out [Namespace] .ParameterValue [] ParámetrosUtilizado, fuera [Namespace] .Warning [] Advertencias de cadena [] StreamIds); Miembro de [Namespace] .ReportingService)
--- donde el formato será "PDF"
Espero que encuentres esto relevante