Seguimos con Access
Como te decía, aquí sigo. He estado realizando algunas pruebas sobre un informe en concreto y ha resultado esto:
- El informe contiene dos subinformes que, a su vez, contienen sendos gráficos. Estos dos subinformes son muy parecidos, sólo cambia una característica de los artículos que salen en ellos.
- El origen de datos de estos subinformes son consultas de referencias cruzadas que se basan en otras consultas que contienen los datos que se necesitan.
- El origen de datos del informe es sólo el año del que van a aparecer los datos. Así, los subinformes están vinculados a este año.
- Nada más abrir la base de datos (programa), ejecutar las consultas de origen (referencias cruzadas) cuesta entre 10 y 15 sg (está muy bien).
- Nada más abrir la base de datos, abrir el informe cuesta unos 6 min. (tela marinera).
- Si hay varios formularios ya abiertos o está abierta la consulta origen, abrir el informe cuesta unos 30 sg. (Ideal de la muerte). Con las consultas no hay diferencia entre ejecutarlas sin haber abierto nada o abriendo datos.
Ya he comprobado los hechos, pero ahora no sé por dónde seguir. Igual esto te ayuda a saber la razón concreta por lo que tarda tanto.
- El informe contiene dos subinformes que, a su vez, contienen sendos gráficos. Estos dos subinformes son muy parecidos, sólo cambia una característica de los artículos que salen en ellos.
- El origen de datos de estos subinformes son consultas de referencias cruzadas que se basan en otras consultas que contienen los datos que se necesitan.
- El origen de datos del informe es sólo el año del que van a aparecer los datos. Así, los subinformes están vinculados a este año.
- Nada más abrir la base de datos (programa), ejecutar las consultas de origen (referencias cruzadas) cuesta entre 10 y 15 sg (está muy bien).
- Nada más abrir la base de datos, abrir el informe cuesta unos 6 min. (tela marinera).
- Si hay varios formularios ya abiertos o está abierta la consulta origen, abrir el informe cuesta unos 30 sg. (Ideal de la muerte). Con las consultas no hay diferencia entre ejecutarlas sin haber abierto nada o abriendo datos.
Ya he comprobado los hechos, pero ahora no sé por dónde seguir. Igual esto te ayuda a saber la razón concreta por lo que tarda tanto.
1 respuesta
Respuesta de asturcon3
1
Access incluye un ""optimizador"" que se basa en la definición de índices y referencias para ejecutar de un modo u otro las consultas. Se basa en los costes estimados, y en función de ello toma una decisión.
El tema es que, por lo que se ve, al abrir por primera vez la consulta del informe debe estar equivocándose, ya que, al ser el primer acceso a esas tablas aún no tiene datos para saber de que forma acceder, luego asume una (la que sea) y... se equivoca.
Supongo que habría mil maneras de solucionar esto de un modo realmente eficaz y elegante, pero a mí se me ocurre que lo más práctico podría ser ejecutar antes que el informe la consulta más rápida que tengas y que haga que el informe vaya más rápido.
Para ello se me ocurren dos posibilidades.
La primera, quizá funcione, no estoy seguro, y es utilizar el evento 'al cargar' del formulario, abriendo la consulta rápida. Digo que igual funciona porque no sé (tendría que probar, te toca a ti) si a esas alturas Access ya ha lanzado la consulta y ya se ha equivocado. Para hacer esto, en el evento 'al cargar' tendrías que ponerle
dim r as recordset
set r=currentdb.openrecordset("select * from miconsultarápida")
Tiene un inconveniente, y es que se lanza cada vez que se abre el informe, independientemente de que sea o no la primera vez. Lo cual me lleva a la segunda:
La segunda: Muy probablemente tendrás un formulario de bienvenida, de entrada o de menú que se abre al cargar el mdb. Si no lo tienes, siempre lo puedes crear nuevo y ponerle dentro 'Bienvenido a este programa'. El tema sería que el mismo código de antes te lo ejecutase en el evento 'al cargar' de ese formulario. ¿Ventajas? Sólo se ejecuta una vez, al abrir la base de datos.
Ahora entenderás porque decía antes que habrá soluciones más elegantes...
Ah, pienso ahora que igual la consulta te la abre muy rápido porque en pantalla sólo te muestra el primer bloque de registros accedidos, los suficientes para lo que tiene que pintar. ¿Sigue siendo rápida si nada más abrirla le das al botón de ir al último? Porque quizá obtener unos pocos registros, digamos 20 en pantalla, es mucho más rápido que obtenerlos todos, digamos 35 trillones.
El tema es que, por lo que se ve, al abrir por primera vez la consulta del informe debe estar equivocándose, ya que, al ser el primer acceso a esas tablas aún no tiene datos para saber de que forma acceder, luego asume una (la que sea) y... se equivoca.
Supongo que habría mil maneras de solucionar esto de un modo realmente eficaz y elegante, pero a mí se me ocurre que lo más práctico podría ser ejecutar antes que el informe la consulta más rápida que tengas y que haga que el informe vaya más rápido.
Para ello se me ocurren dos posibilidades.
La primera, quizá funcione, no estoy seguro, y es utilizar el evento 'al cargar' del formulario, abriendo la consulta rápida. Digo que igual funciona porque no sé (tendría que probar, te toca a ti) si a esas alturas Access ya ha lanzado la consulta y ya se ha equivocado. Para hacer esto, en el evento 'al cargar' tendrías que ponerle
dim r as recordset
set r=currentdb.openrecordset("select * from miconsultarápida")
Tiene un inconveniente, y es que se lanza cada vez que se abre el informe, independientemente de que sea o no la primera vez. Lo cual me lleva a la segunda:
La segunda: Muy probablemente tendrás un formulario de bienvenida, de entrada o de menú que se abre al cargar el mdb. Si no lo tienes, siempre lo puedes crear nuevo y ponerle dentro 'Bienvenido a este programa'. El tema sería que el mismo código de antes te lo ejecutase en el evento 'al cargar' de ese formulario. ¿Ventajas? Sólo se ejecuta una vez, al abrir la base de datos.
Ahora entenderás porque decía antes que habrá soluciones más elegantes...
Ah, pienso ahora que igual la consulta te la abre muy rápido porque en pantalla sólo te muestra el primer bloque de registros accedidos, los suficientes para lo que tiene que pintar. ¿Sigue siendo rápida si nada más abrirla le das al botón de ir al último? Porque quizá obtener unos pocos registros, digamos 20 en pantalla, es mucho más rápido que obtenerlos todos, digamos 35 trillones.
Muchas gracias por todo. Pero resulta que encontré un modo de acelerar siempre el acceso a los datos (ya sea para mostrar un formulario como para obtener un informe). Se trata, como más o menos dices tú, de abrir el recordset antes de acceder a los datos. Es sencillo y muy eficaz. Así logré reducir de 9 min a 40 sg. la obtención en pantalla de un informe que tenía con varios subinformes y varios gráficos. Supongo que no es lo más "elegante" del mundo, pero como no lo tengo que lucir por las pasarelas, me sirve perfectamente.
Te agradezco un montón tu atención. Gracias,
Tony.
Te agradezco un montón tu atención. Gracias,
Tony.
