Cita:
|
Empezado por hgiacobone
...Lo que me gustaría saber es si la gran mayoría considera esto como la mejor solución o piensan que es recargar al producto final con componentes en demacía.
...
Ciertos amigos, me comentan que son mejores y más confiables los comoponentes de acceso a datos de los Reporteadores que los propios del entorno, cuestión que me parece improbable.
...
Lo cierto es que tener 2 DataSource dentro del sistema (uno en el DataModule o Form y otro en el Reporter) para obtener la misma vista de datos, suena a cosa de locos, por más "Top" que lo pinten.
|
Creo que no es cuestión de "mejor" ni "peor" sino de cosas diferentes. Me da la impresión de que la solución de Crystal/Rave/... es una solución más genérica.
Tiene las ventajas de que independizas los reportes de tu aplicación.
* El trabajo deja de hacerlo tu aplicación, ya que los datos no pasan por ella, directamente los obtiene el report.
* Puedes lanzar los mismos Reports desde dos aplicaciones distintas, una hecha en Delphi y otra en Web que estén trabajando sobre los mismos Datos (digo estas dos por decirte algo).
* Si cambias de programa, los listados siguen siendo validos (Crystal por ejemplo, tiene componentes de acceso para casi todos los programas)
* No siempre los datos del listado son los mismos que los del programa. A veces la consulta/s necesarias para el listado no las necesitas para nada en el programa, deberías generarla expresamente para "pasarle" los datos al Report.
Por contra éstos generadosres se suelen integrar peor con los programas, que los que se basan en DataSets (QR, FR, ...), suelen tener más problemas de instalación, son peores a la hora de pasarles parámetros (relacionado con la integración,...)
Incluso no creo que sean excluyentes. Nosotros solemos utilizar una solución mixta. Hay reportes sencillos (sábanas), algunas exportaciones directas desde los DBGrids y demás para los que utilizamos QR, y otros listados más complejos y temas estadísticos para los que utilizamos Generadores externos (Adobe Output Server).