acelarar la carga de crystal report

07/03/2007 - 12:11 por kiko | Informe spam
Hola grupo. Tengo una aplicación que la primera vez que muestra un informe
tarda mucho, sin embargo en los sucesivos informes el tiempo de carga es
bastante menor. ¿sabéis como se puede acelerar la carga de crystal report
haciendo que por ejemplo al inicio de la aplicación se pre-carguen las
librerías?

Gracias a todos,

Kiko

Preguntas similare

Leer las respuestas

#6 Octavio Hernandez
07/03/2007 - 18:00 | Informe spam
Juan,

Bueno, mi propuesta era para los casos en q no se usan DataSets...
Tiene muy buena pinta eso que dices de precargar los datos en memoria.
Claro, se puede hacer prohibitivo para conjuntos de datos grandes.
Una pregunta, lo de "Moondance" es por Van Morrison?

Slds - Octavio



"Juan Diego Bueno" escribió en el mensaje
news:
Yo corroboro lo dicho por Juanjo, ya lo he puesto en algún que otro
hilo. Aún así, tarda un poco en generarse, de ahí que plantee esa
solución de pre-cargar el form y luego llamar o no a esa instancia. En
el constructor del form, hacer un primer fill sobre una consulta muy
común, y para sucesivas llamadas, cambiar el origen de datos del
informe a medida en el evento Load().

No he leido lo que ha propuesto Octavio, pero seguro que es útil.

Saludos

On 7 mar, 16:53, "[Juanjo]" wrote:
Hola:

Segun mi experiencia pasale al crystal report los datos ya
preparados desde un
dataset,datatable,etc mejor que sea el crystal report el que se conecte a
la
base de datos
y haga el la consulta. Te ira mas rapido.

Un saludo.

"kiko" escribió en el
mensajenews:

> Hola grupo. Tengo una aplicación que la primera vez que muestra un
> informe
> tarda mucho, sin embargo en los sucesivos informes el tiempo de carga es
> bastante menor. ¿sabéis como se puede acelerar la carga de crystal
> report
> haciendo que por ejemplo al inicio de la aplicación se pre-carguen las
> librerías?

> Gracias a todos,

> Kiko
Respuesta Responder a este mensaje
#7 Juan Diego Bueno
07/03/2007 - 19:38 | Informe spam
Sí, Octavio, aunque te responda con la otra cuenta, lo de Moondance es por
el glorioso disco de Van Morrison.
Respecto a lo de precargar los datos... me queda la duda de si la apertura
del informe se retrasa con la creación del visor y la llamada a los
componentes Crystal o simplemente responde a la cantidad de datos (contando
con una cantidad de registros moderada-grande, claro). De ser la primera
opción, con generar un informe de una vista con un solo registro, sobraría y
no sobrecargaría el sistema. Si me decido a probarlo cuando tenga tiempo, lo
comunicaré oportunamente.

Saludos

"Octavio Hernandez" escribió en el mensaje
news:O$
Juan,

Bueno, mi propuesta era para los casos en q no se usan DataSets...
Tiene muy buena pinta eso que dices de precargar los datos en memoria.
Claro, se puede hacer prohibitivo para conjuntos de datos grandes.
Una pregunta, lo de "Moondance" es por Van Morrison?

Slds - Octavio



"Juan Diego Bueno" escribió en el mensaje
news:
Yo corroboro lo dicho por Juanjo, ya lo he puesto en algún que otro
hilo. Aún así, tarda un poco en generarse, de ahí que plantee esa
solución de pre-cargar el form y luego llamar o no a esa instancia. En
el constructor del form, hacer un primer fill sobre una consulta muy
común, y para sucesivas llamadas, cambiar el origen de datos del
informe a medida en el evento Load().

No he leido lo que ha propuesto Octavio, pero seguro que es útil.

Saludos

On 7 mar, 16:53, "[Juanjo]" wrote:
Hola:

Segun mi experiencia pasale al crystal report los datos ya
preparados desde un
dataset,datatable,etc mejor que sea el crystal report el que se conecte a
la
base de datos
y haga el la consulta. Te ira mas rapido.

Un saludo.

"kiko" escribió en el
mensajenews:

> Hola grupo. Tengo una aplicación que la primera vez que muestra un
> informe
> tarda mucho, sin embargo en los sucesivos informes el tiempo de carga
> es
> bastante menor. ¿sabéis como se puede acelerar la carga de crystal
> report
> haciendo que por ejemplo al inicio de la aplicación se pre-carguen las
> librerías?

> Gracias a todos,

> Kiko








Estoy utilizando la versión gratuita de SPAMfighter para usuarios privados.
Ha eliminado 9318 correos spam hasta la fecha.
Los abonados no tienen este mensaje en sus correos.
¡Pruebe SPAMfighter gratis ya!
Respuesta Responder a este mensaje
#8 Octavio Hernandez
07/03/2007 - 19:50 | Informe spam
Sí, Octavio, aunque te responda con la otra cuenta, lo de Moondance es por
el glorioso disco de Van Morrison.



Pues entonces, amigo, probablemente tendrás más o menos los mismos años que
yo (en mi caso, más de los que quisiera, je, je...)

Respecto a lo de precargar los datos... me queda la duda de si la apertura
del informe se retrasa con la creación del visor y la llamada a los
componentes Crystal o simplemente responde a la cantidad de datos
(contando con una cantidad de registros moderada-grande, claro). De ser la
primera opción, con generar un informe de una vista con un solo registro,
sobraría y no sobrecargaría el sistema. Si me decido a probarlo cuando
tenga tiempo, lo comunicaré oportunamente.



La carga de los componentes de Crystal (solo una vez) y la creación del
visor hay que
hacerlas en cualquier caso, no?

Slds - Octavio
Respuesta Responder a este mensaje
#9 Juan Diego Bueno
07/03/2007 - 21:09 | Informe spam
Si te refieres a la precarga, yo lo que propongo es crear una instancia de
ese formulario generando un informe sobre la base de datos (a ser posible,
el más demandado) sin mostrar ese form a la apertura de la aplicación
mientras al usuario se le muestra una pantalla de bienvenida o un splash.
Con el patrón singleton, yo ya puedo hacer referencia a esa instancia usando
definstance, y cuando el usuario pida un informe, se hace un show sobre ese
definstance. Con algún tipo de flag, se podría detectar si los datos pedidos
son los ya precargados u otros. En el primer caso, creo que sería
instantáneo el mostrarlo (aunque no lo he probado), mientras que en el
segundo, utilizando el form_load, haríamos los fill sobre los tableadapters
correspondientes al informe pedido, y supongo que tardaría un poco más. Todo
eso teniendo en cuenta que supuestamente las sucesivas cargas del visor y
del informe son mucho más rápidas. Insisto, es solo teórico, no lo he
probado, pero podría valer.

Y respecto a la edad... son más de 35 y menos de 40, pero escucho música de
todas épocas, incluidas de antes de nacer yo.

Saludos


"Octavio Hernandez" escribió en el mensaje
news:
Sí, Octavio, aunque te responda con la otra cuenta, lo de Moondance es
por el glorioso disco de Van Morrison.



Pues entonces, amigo, probablemente tendrás más o menos los mismos años
que
yo (en mi caso, más de los que quisiera, je, je...)

Respecto a lo de precargar los datos... me queda la duda de si la
apertura del informe se retrasa con la creación del visor y la llamada a
los componentes Crystal o simplemente responde a la cantidad de datos
(contando con una cantidad de registros moderada-grande, claro). De ser
la primera opción, con generar un informe de una vista con un solo
registro, sobraría y no sobrecargaría el sistema. Si me decido a probarlo
cuando tenga tiempo, lo comunicaré oportunamente.



La carga de los componentes de Crystal (solo una vez) y la creación del
visor hay que
hacerlas en cualquier caso, no?

Slds - Octavio





Estoy utilizando la versión gratuita de SPAMfighter para usuarios privados.
Ha eliminado 9318 correos spam hasta la fecha.
Los abonados no tienen este mensaje en sus correos.
¡Pruebe SPAMfighter gratis ya!
Respuesta Responder a este mensaje
#10 Octavio Hernandez
07/03/2007 - 23:59 | Informe spam
Juan,

Mantenme al tanto de los experimentos...

Slds - Octavio



"Juan Diego Bueno" escribió en el mensaje
news:%
Si te refieres a la precarga, yo lo que propongo es crear una instancia de
ese formulario generando un informe sobre la base de datos (a ser posible,
el más demandado) sin mostrar ese form a la apertura de la aplicación
mientras al usuario se le muestra una pantalla de bienvenida o un splash.
Con el patrón singleton, yo ya puedo hacer referencia a esa instancia
usando definstance, y cuando el usuario pida un informe, se hace un show
sobre ese definstance. Con algún tipo de flag, se podría detectar si los
datos pedidos son los ya precargados u otros. En el primer caso, creo que
sería instantáneo el mostrarlo (aunque no lo he probado), mientras que en
el segundo, utilizando el form_load, haríamos los fill sobre los
tableadapters correspondientes al informe pedido, y supongo que tardaría
un poco más. Todo eso teniendo en cuenta que supuestamente las sucesivas
cargas del visor y del informe son mucho más rápidas. Insisto, es solo
teórico, no lo he probado, pero podría valer.

Y respecto a la edad... son más de 35 y menos de 40, pero escucho música
de todas épocas, incluidas de antes de nacer yo.

Saludos


"Octavio Hernandez" escribió en el mensaje
news:
Sí, Octavio, aunque te responda con la otra cuenta, lo de Moondance es
por el glorioso disco de Van Morrison.



Pues entonces, amigo, probablemente tendrás más o menos los mismos años
que
yo (en mi caso, más de los que quisiera, je, je...)

Respecto a lo de precargar los datos... me queda la duda de si la
apertura del informe se retrasa con la creación del visor y la llamada a
los componentes Crystal o simplemente responde a la cantidad de datos
(contando con una cantidad de registros moderada-grande, claro). De ser
la primera opción, con generar un informe de una vista con un solo
registro, sobraría y no sobrecargaría el sistema. Si me decido a
probarlo cuando tenga tiempo, lo comunicaré oportunamente.



La carga de los componentes de Crystal (solo una vez) y la creación del
visor hay que
hacerlas en cualquier caso, no?

Slds - Octavio





Estoy utilizando la versión gratuita de SPAMfighter para usuarios
privados.
Ha eliminado 9318 correos spam hasta la fecha.
Los abonados no tienen este mensaje en sus correos.
¡Pruebe SPAMfighter gratis ya!


Respuesta Responder a este mensaje
Ads by Google
Help Hacer una preguntaSiguiente AnteriorRespuesta Tengo una respuesta
Search Busqueda sugerida