FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
||||
|
||||
El gran dilema de la impresión
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?
__________________
Gracias de antemano por vuestra ayuda. ·.:*:.·Yako·.:*:.· |
#2
|
||||
|
||||
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.
__________________
Guía de Estilo de los Foros Cita:
Última edición por marcoszorrilla fecha: 19-04-2005 a las 14:57:10. |
#3
|
||||
|
||||
Hola mi estimado Marcos... tanto tiempo!
Cita:
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.
__________________
Gracias de antemano por vuestra ayuda. ·.:*:.·Yako·.:*:.· |
#4
|
||||
|
||||
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.
__________________
Guía de Estilo de los Foros Cita:
Última edición por marcoszorrilla fecha: 19-04-2005 a las 14:56:51. |
#5
|
|||
|
|||
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 |
#6
|
||||
|
||||
Cita:
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).
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. |
|
|
|