acelarar la carga de crystal report

Yo no me he dedicado a comprobar la carga de los componentes, pero en
una web que hacia una consulta sobre una base de datos de unos 150.000
registros
y mostraba un informe de esta consulta (informes de una pagina del estilo,
los X mayores registros,
los X mas vendidos y luego informes de un listado de los registros) (aunque
el equipo no
era un Pentium 27):
- Si la consulta la realizaba desde el propio informe sobre la base de
datos, la pagina daba error
porque excedia el tiempo de espera a la respuesta del servidor.
- Si hacia la consulta en la "propia pagina web" y luego pasaba los datos
con un datatable no tardaba
mas de 10 seg (hablando que era una web con una linea adsl 20 mb y un k7
900Mhz esta bastante bien)

Despues de muchas horas y muchas web leidas, y casi destripar los fuentes
del crystal, pienso (es mi
opinion) que el crystal trae todos los datos y cuando los tiene hace el
where, porque daba igual las
condiciones "where" que pusiera, tardaba igual, de hecho si miras la
consulta que genera el crystal
no tiene ni un "where", el where solo lo haces cuando pones las condiciones
de los datos que quieres
mostrar, y para eso tienes que tener los datos en el informe, asi que
siempre recogia los 150.000 registros
en mi caso. Si haces la consulta en el formulario ya estas cogiendo los
datos que vas a mostrar, y solo
tardas lo que que tardas en ejecutar la consulta (el tiempo de carga del
componente crystal es el mismo
en ambos casos).

Espero no estar muy equivocado en mis afirmaciones (jeje)

Un saludo.

"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!

Para Octavio:

Con la precarga del informe no se acelera nada. En mi caso tarda 4
segundos en generar un informe sobre 138 registros de lo que se deduce
que la tardanza es simplemente debida a la toma de datos del sgbd
siendo despreciable la creacion de objetos crystal.

Para Juanjo:

Si es así, segun cuentas... quizás la mejor opción sea crear vistas
dinámicamente con los filtros ya aplicados. Así solo se traería los
datos necesarios (que por cierto, es un sistema que usan muchos de mis
compañeros).

Habrá que probarlo...

Saludos

On 8 mar, 09:47, "[Juanjo]" wrote:

Yo no me he dedicado a comprobar la carga de los componentes, pero en
una web que hacia una consulta sobre una base de datos de unos 150.000
registros
y mostraba un informe de esta consulta (informes de una pagina del estilo,
los X mayores registros,
los X mas vendidos y luego informes de un listado de los registros) (aunque
el equipo no
era un Pentium 27):
- Si la consulta la realizaba desde el propio informe sobre la base de
datos, la pagina daba error
porque excedia el tiempo de espera a la respuesta del servidor.
- Si hacia la consulta en la "propia pagina web" y luego pasaba los datos
con un datatable no tardaba
mas de 10 seg (hablando que era una web con una linea adsl 20 mb y un k7
900Mhz esta bastante bien)

Despues de muchas horas y muchas web leidas, y casi destripar los fuentes
del crystal, pienso (es mi
opinion) que el crystal trae todos los datos y cuando los tiene hace el
where, porque daba igual las
condiciones "where" que pusiera, tardaba igual, de hecho si miras la
consulta que genera el crystal
no tiene ni un "where", el where solo lo haces cuando pones las condiciones
de los datos que quieres
mostrar, y para eso tienes que tener los datos en el informe, asi que
siempre recogia los 150.000 registros
en mi caso. Si haces la consulta en el formulario ya estas cogiendo los
datos que vas a mostrar, y solo
tardas lo que que tardas en ejecutar la consulta (el tiempo de carga del
componente crystal es el mismo
en ambos casos).

Espero no estar muy equivocado en mis afirmaciones (jeje)

Un saludo.

"Juan Diego Bueno" escribió en el mensajenews:%

> 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!

Bueno, en ese carga, haria falta comparar si crystal report tiene mejor
acceso a datos que el VC#,
pero no creo que uno vaya a ser muchisimo mejor que el otro.

Saludos.

"Juan Diego Bueno" escribió en el mensaje
news:
Para Octavio:

Con la precarga del informe no se acelera nada. En mi caso tarda 4
segundos en generar un informe sobre 138 registros de lo que se deduce
que la tardanza es simplemente debida a la toma de datos del sgbd
siendo despreciable la creacion de objetos crystal.

Para Juanjo:

Si es así, segun cuentas... quizás la mejor opción sea crear vistas
dinámicamente con los filtros ya aplicados. Así solo se traería los
datos necesarios (que por cierto, es un sistema que usan muchos de mis
compañeros).

Habrá que probarlo...

Saludos

On 8 mar, 09:47, "[Juanjo]" wrote:

Yo no me he dedicado a comprobar la carga de los componentes, pero en
una web que hacia una consulta sobre una base de datos de unos 150.000
registros
y mostraba un informe de esta consulta (informes de una pagina del estilo,
los X mayores registros,
los X mas vendidos y luego informes de un listado de los registros)
(aunque
el equipo no
era un Pentium 27):
- Si la consulta la realizaba desde el propio informe sobre la base de
datos, la pagina daba error
porque excedia el tiempo de espera a la respuesta del servidor.
- Si hacia la consulta en la "propia pagina web" y luego pasaba los datos
con un datatable no tardaba
mas de 10 seg (hablando que era una web con una linea adsl 20 mb y un k7
900Mhz esta bastante bien)

Despues de muchas horas y muchas web leidas, y casi destripar los fuentes
del crystal, pienso (es mi
opinion) que el crystal trae todos los datos y cuando los tiene hace el
where, porque daba igual las
condiciones "where" que pusiera, tardaba igual, de hecho si miras la
consulta que genera el crystal
no tiene ni un "where", el where solo lo haces cuando pones las
condiciones
de los datos que quieres
mostrar, y para eso tienes que tener los datos en el informe, asi que
siempre recogia los 150.000 registros
en mi caso. Si haces la consulta en el formulario ya estas cogiendo los
datos que vas a mostrar, y solo
tardas lo que que tardas en ejecutar la consulta (el tiempo de carga del
componente crystal es el mismo
en ambos casos).

Espero no estar muy equivocado en mis afirmaciones (jeje)

Un saludo.

"Juan Diego Bueno" escribió en el
mensajenews:%

> 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!