El gran dilema de la impresión

[hgiacobone]

Hola amigos,
Bueno, no sé si es para tanto, pero seguramente unos de los dilemas más discutidos entre nos (o sea los programadores) es a la hora de generar los reportes impresos con datos obtenidos mediantes consultas SQL.

En este punto nos encontramos en que hoy es posible generar la consulta SQL desde el generador de Reportes incluyendo en este, componentes que acceden directamente a los datos, pero ¿qué pasa con los componentes que ya tengo en mi DataModule (o ficha, para los mas desprolijos)?. Estoy duplicando mis componentes de acceso innecesariamente, ya que pues, debería con los datos obtenidos por ejemplo con un simple TDataModule poder mostrarlo por pantalla y por impresión (salidas del sistema).

¿Les parece que es mejor manipular los datos de manera centralizada a la vieja usanza con los componente del DataModule y luego imprimír vía código o incorporara esta "fantástica solucion" de los productos reporteadores?

[marcoszorrilla]

Supongo que te estas refiriendo a Crystal Report, porque ocn QuickReport por ejemplo aprovechas los Datamodulos con las consulta que tengas y tomas los datos directamente de estas.

Un Saludo.

[hgiacobone]

Hola mi estimado Marcos... tanto tiempo!

Empezado por marcoszorrilla

Supongo que te estas refiriendo a Cristal Report...

...y no tanto. Yo me refiero más bien al nuevísimo RAVE-Reports, que la gente que lo desarrolla "recomienda" utilizar esta metodología.

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.

[marcoszorrilla]

Yo creo que esto se debe más a que estos programas tienen un propósito general y no están hechos en principio para trabajar con ningún tipo de lenguaje en concreto, pero me parece un consumo de recursos innecesario y una duplicación el tener una consulta o vista realizada y no poderla aprovechar para crear un informe a partir de ella, eso me pasa a mí cuando utilizo por ejemplo Crystal con Access y VB.

Me parece más lógico lo que hace Qr, que se conecta directamente a cualquier Dataset que tengamos, sea de consulta, tabla o vista.

Esto sin entrar en el tema de las DLLs, en concreto con Cristal en una aplicación antigua, tenemos un Bat, para que cuando entra cierto programa que también utiliza Crystal pero una versión más moderna, nos copie las Dlls. de una carpeta y machaque las que tenemos, pues sino no funciona este programa y luego al salir nos deje las anteriores, para que funcione el otro....

Un Saludo.

[oscorm]

vamos a ver, el datamodule ha sido, desde su origen una herramienta con una potencia increible, desde poder gestionar la integridad referencial a nivel del cliente hasta hacer del mismo, un repositorio de funcionalidad variada, ahora claro, el tema de los RAVE (me rechina porque lo veo un rollo patatero) o de la impresión, creo yo que si se puede abstraer en la capa del datamodule, tendras centralizada también esa gestión y desde luego que eso mola mazo.
por otra parte, habria que ver la aplicación pero en cualquier caso, puedes tener la gestión de la impresión en el datamodule, y las fuentes de datos declarados en cada formulario, y con un poco de imaginación te aseguro que te montas lo que quieras tu, impresión, I.R. de BBDD, funciones globales, etc.
un saludo

[Neftali [Germán.Estévez]]

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).