ADOTable y ACCESS lentos al cargar

[[Al González]]

¡Hola!

No te preocupes, lo que experimentas ahora es parte de un proceso cotidiano de aprendizaje en el que terminas comprendiendo por qué muchas veces es mejor utilizar bases de datos cliente-servidor y por qué en la mayoría de los casos no tiene lógica alguna leer de la base de datos todos los registros de una tabla.

La lentitud que presenta ahora tu programa es normal debido a la gran cantidad de bytes que estás "jalando" de la base de datos (los procesadores y los cables de red tienen sus límites ).

Empezado por Chogo

La mas grande tiene 279,133 registros. ¿ creen que son demasidos registros para no usar Adotable?

Depende para qué uses ese componente tabla. Si es para imprimir un listado de todos esos 279133 registros, o bien para exportar, vaciar o transmitir toda la tabla a donde se requiere por parte de otro sistema, podría tener sentido. Pero si sólo la abres para captura y, durante dicha sesión, tu aplicación emplea solamente un porcentaje menor de todos esos registros, cargar en memoria esa gran mayoría que no se utiliza para nada es un enorme desperdicio de recursos (tiempo).

Debes acostumbrarte a ver a las bases de datos como un almacén y no como un remolque, no puedes andar llevando la bodega de aquí para allá, como si nada. Las aplicaciones deben tomar de la base de datos solamente la información que requieren, grabando en ellas resultados de sus procesos.

Para permitirle al usuario navegar en una tabla y capturar información en ella, generalmente hago una apertura de la misma trayéndome tan solo las últimas 100 filas que fueron modificadas. Y cuando el usuario desea ver otros registros, le proporciono mecanismos de búsqueda que utilizan un "data set" alterno parametrizado e integran los resultados al listado que ya tengo abierto. Para esto es importante utilizar componentes que te permitan discriminar registros en la extracción de la base de datos que realizan internamente. Casi* ningún componente "Table" te permite hacer esa discriminación, por lo que usualmente se aconseja la alternativa de los componentes "Query", ya que en estos colocas una sentencia SQL Select que lleva condiciones en su cláusula Where para "sacar" de la base de datos sólo ciertos registros.

Empezado por Chogo

Gracias por tu pronta repuesta pero lo que pasa es que son como unos 40 adotables. No puedo cambiarlos a esta hora del partido.

Si hicera eso como haria con los formulario maestro-detalle los adoquery no estan diseñados para eso. habria que programar mas.

Todo error de diseño tiene sus consecuencias, Chogo. Pero para eso están estos foros . Vayamos por partes:

Por un lado los componentes Query sí pueden establecerse en relaciones maestro-detalle. En la Red y en estos mismos foros podrás encontrar muchos ejemplos.

Por otra parte, si tu aplicación corresponde a las características típicas de un programa de gestión, es muy probable que sólo unas cuantas tablas tengan miles de registros (¿o acaso las 40 almacenan casi 300 mil?). Podrías empezar por convertir a TADOQuery los cuatro o cinco TADOTable más críticos, como medida de alivio transitorio. Después tendrás más tiempo para revisar tu proyecto a profundidad y plantearte seriamente el usar una base de datos más adecuada (cliente-servidor, como Firebird, por ejemplo).

Espero te resulte orientadora mi aportación.

Un abrazo selectivo.

Al González.

*Por mi experiencia con los componentes IBX, sé que TIBTable maneja la carga de registros de manera eficiente al establecer un valor en su propiedad Filter antes de la apertura (con Filtered en True, desde luego). Internamente se ejecuta una consulta Select con cláusula Where, donde ésta lleva como condiciones el texto de la propiedad Filter. No conozco a fondo el componente TADOTable, pero dudo que haga lo mismo.